Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Build DAG from functions directly

Đang mở
  • Có gì không ổn?
#1,268 7 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
python
Lĩnh vực
compilers, data-engineering

Hướng nghiên cứu

Bắt đầu với đường dẫn ad_hoc_utils hiện có và điểm vào Builder().with_modules() để hiểu cách các đối tượng hàm hiện được chuyển đổi thành DAG. Issue không nêu tên tệp hoặc test nào; để hoàn tất, cần chọn và ghi lại một API dựa trên hàm được hỗ trợ, bao phủ API đó bằng các test và giữ nguyên workflow tải module hiện có.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

core-work question

Summary

Add first-class way to build a DAG from function objects (in contrast to DIY/ hacky). The user API could be either:

  • Builder().with_functions()
  • or an intermediary my_module = module_from_functions(fns*) then passed to .with_modules()

Goals:

  • simplify codebase
  • foundation for better hierarchical / nested graph structures (i.e., subdags)

Current

At the core of Hamilton, users:

  1. write functions in a Python module ("dataflow code")
  2. load that module in the "driver code" to build a DAG
  3. execute the DAG via the Driver

Problem

  • It is currently possible to build Hamilton DAGs from functions, but we have no official "here's how you do it" that we guarantee we'll support.
    • ad_hoc_utils means exactly the opposite
  • In a notebook, there's no good reason to create a module from a notebook function before passing to Hamilton (except our how constraints)
  • Python module machinery is complex and adds indirection to the codebase (tests, notebook extension, LSP)

Benefits

  • greatly simply many unit tests
  • facilitate marimo integration

Hamilton 2.0 / Broader perspective

There's no well-defined structure or purpose to Hamilton top-level modules (e.g., nodes, graph_types, graph_utils, graph, ad_hoc_utils, base, hamilton.common, models). I propose a structure that matches the Hamilton lifecycle:

  • hamilton.parser: everything that deals with source code: how functions are written, if type annotations are present (not type matching), collecting functions from modules, converting a notebook cell string to a module, remove comments and docstring before hashing source code
  • hamilton.compiler: converting code to DAG: structuring the DAG from functions, applying function modifiers, validating types, etc.
  • remove ad_hoc_utils
Ngôn ngữ chính
Jupyter Notebook
Star
2.6k
Fork
221
Merge trung bình
2 ngày 1 phút
Pull request đã merge (30 ngày)
17

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/hamilton

Tất cả issue của apache/hamilton

Issue tương tự

Thêm issue về Compilers

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.