[Request for Feedback] Dynamo Graph Package Dependency Display

If your IT isn’t ok with people downloading DLLs off of package manager, would they be ok with DLLs somehow being baked into DYNs, and the DYNs being distributed?

Just to clarify, my statement about DLLs is not related to what IT wants to do. Microsoft’s security policies block loading DLLs from network shares.

I guess if you have to share something with a DLL you would have to trigger a download from an external source down to your local drive. Otherwise, being able to “pack and go” content with python, out of the box nodes, or designscript code would be beneficial.

My preference would be to have the package name in the node title (or an an option to turn this display on)
I guess the only issue might be the text length in some cases i.e “BimorphNodes.Curve.RemoveDuplicates”


For the help- I think the right click option is fine- but as you say, just as long as it is easy to find out


I agree a ‘pack & go’ utility would be good for publishing & distributing complete Dynamo graphs.

I guess the downside is that you could end up with a lot of duplication, or old package versions embedded in the published graphs (but at least they should work reliably and not depend upon locally installed packages)


1 Like

While I’m sure this is a problem in need of solving, it looks like that right-side panel being used just for looking up which packages are missing is a waste of screen-space. There could be a window like a console that you get fo that type of thing. If there were a right side panel I would love to see “Favourites Components” or some customizable toolbars, or different shading modes… stuff one uses every time the program is open, not stuff that just needs occasional checking.

This may be a relevant related topic: Call for Feedback on Extensions on Dynamo Right Side Panel


1 Like

Haha, alright, sorry!

Data shapes has an option to prepend this information. I also added a view extension to Rhythm that does this upon node placement for Rhythm nodes in 2.0. :grin: image


o.k thanks John
you are one (probably way more than one) step ahead of me

1 Like

lol, just wanted to make sure to share how I implemented similar functionality in Rhythm. :slight_smile:

The issue is that all downloads are blocked by default. So they don’t even have the option to download anything from the package manager. Part of my job in dealing with all things Dynamo is to download, maintain, and distribute the proper files. So this is really a discussion about what works for me (or other “distributer” types in similar situations). I see this as a way to streamline and automate part of the distribution process.

But that also brings up the valid point of what happens if you don’t want users to be able to download and update DLLs and DYFs?

1 Like

That kind of depends on if or how the nodes get serialized. If they’re dependent on package version then yes, you could end up with duplicates and multiple versions. Which isn’t necessarily terrible. It would just be another way to help you see what you’re currently using and perhaps let you know that some graphs need to be updated.

If the nodes aren’t dependent on package version and Dynamo just uses the latest version you have installed (like it does now) you wouldn’t have to worry about updating individual graphs when you update your packages.

Dynahub is amazing and I think the team has quite a bit to learn from it!

That being said, the most important part of this overall conversation to me is to finally have some sort of way to serialize package infos in the Dynamo graph (.dyn) itself. I look forward to the day that I do not have to add that little note in all graphs that everyone ignores.

I can honestly care less about “auto package download” or, “embedded packages in dyn” and all of that “magic” part of the discussion.

What I want out of this whole effort:

  • User Downloads .dyn and is missing packages
  • Alert pops up to warn them: “Oh look this says I need to download Lunchbox, Clockwork and archilab”
  • User gets the package whatever way they need to. (Based on their specific abilities, permissions, etc.)

But, if the team wants to get hung up on “magic” workflows and automating all the things, then I will just keep authoring Dynamo graphs the same way anyway by adding a note above each node indicating package name and package version. Then we have yet another feature in Dynamo that some people find cool, (examples include the now retired presets functionality, show/hide upstream geometry preview, Revit text outline preview in Dynamo and customizer/web publish functionality).

If I recall correctly, grasshopper has an awesome way of alerting users about dependencies. (Correct me if I am wrong as I haven’t used grasshopper in a while)

*EDIT- Kristen from Proving Ground was nice enough to share the image of the grasshopper version:

I like that it offers the option to download, but if you can’t (no permissions, etc), you at least know what the issue is with your script.


I am going to agree with @john_pierson here. +1 :+1: :snowflake:

I am impressed that this topic contains a great collaboration of ideas all :slightly_smiling_face: and am sure all have been super helpful for the development team. I can’t wait to see a result :star_struck:


Hey @Qilong_Tang,
where are we at with all these ideas?

otherwise stated with a French accent:

Ou air art oui ate?


Hi @Jean-Marc and others who are still watching

Thank you for checking in. If you have been following our daily builds. This extension has made into the 2.3 builds, our team are testing different cases with package dependency display. Some design work is happening even before resolving the dependencies. Currently we have encountered four cases, as some of these cases are covered by the comments in this thread (tremendously helpful).

  • Exact version of Package Dependency is installed and loaded locally
  • Different version of Package Dependency is installed and loaded locally
  • Package Dependency is not installed locally
    • Package Dependency is not installed locally, but some or all of its dependent nodes are resolved by a different local package.
    • Package Dependency has been changed and is awaiting a restart of Dynamo

Our team is committed to address all of these cases and inside the team we have kind agreed that we will provide our way of resolving dependencies but no hidden magic based on the comments you have given in this thread. User could totally ignore and resolve by doing something by themselves. This work also helped us to find some bugs and workflow has been wrong the whole time. We are in the way fixing them. So stay tuned!


If that is the case- drop back to a .net implementation of dynamo with exposed classes to the nodes instead of whatever Dynamo is…

Is part of why I keep trying to get back into API coding to create embedded solutions- I just miss the step-through I had with VBA in other applications and being able to snoop parameters or classes on the fly. There is just too much in the database to ‘know’ when programming is a side implementation to the production work we do daily.

  1. This is exactly what I’ve been looking for. Recently started working at a new architectural firm which has an existing library of Dynamo Player graphs utilizing multiple packages — of which, I have no idea what version to download.
  2. A magic download button would be great!

Thank you for doing this!

  1. it looks great! I like it.
  2. yes, magic download button would be good.
1 Like