This message was deleted.

So yeah — a bit nuanced but could probably do better in the docs to explain: 1. A Node is the internal API — we reserve the right to change it without bumping major versions (there’s an internal class) 2. A “variable” is the user-facing API — this gives you information about “nodes” (as in DAG nodes) 3. The string is how you refer to it when you execute a dag For (1)>(3) we have list_available_variables, so you have to build a map. Having a “get_variable” fn wouldn’t be crazy…

Yes, a get_variable(node_name: str) is kinda what I hacked together digging into the APIs. It’s useful at times to get meta data from the Variable, e.g. to map node_name string to Python function that gets called

Yep! Makes sense. We can probably add something like that in — should be easy (we have the mapping in driver)

> Context: I built a tool to map from node_name to file + line number in my git repo to quickly navigate to the definition of a node where/how do you use it? Also @Thierry Jean started https://marketplace.visualstudio.com/items?itemName=ThierryJean.hamilton but we haven’t had much time to push it forward more.

Hey! Since Hamilton uses basic Python functions, the Outline view in VSCode can help you navigate a large file. A core limitation that your approach and the extension try to overcome is that some Hamilton functions don't directly map to a node (e.g., decorators, materializers) I built the VSCode extension a few months ago, but consider it very much experimental since we are still figuring out the best IDE experience. Let me know if you find it interesting and if you have any feature request 🙂

@Stefan Krawczyk imaging the case where I have 10+ folks building all kinds of Hamilton nodes across various modules. I’m building a sort of Data Catalog in Streamlit, that lets me easily explore which Hamilton nodes exist for a given business line, and then allow me quickly to jump to their definition in my GitHub via clickable links. I have a toy example here (without clickable links), @Elijah Ben Izzy already took it for a spin: https://github.com/kzk2000/hamilton-playground/blob/main/toy3_streamlit_run.py

Cool @miek. Would that be integrated with that app then? So by analogy with the streamlit app, e.g. given a ticker, what “fields” are defined for it — I want to know more — click and see the code for that definition?

Yes, I don’t have it in this toy app but in my prototype at work. You basically print a Lineage table for each node you selected in the app, with their upstream and downstream nodes as clickable links that then jump to their GitHub repo line where it’s defined