Call for Feedback on Dynamo Graph Package Dependency Display

Too late, it’s already on the internet. :stuck_out_tongue_winking_eye:

But for real. Please please please please Dynamo Team. Do not hide this info in some non-user-readable way. (is 4 pleases enough?)


They always try (even for just one please). There are some limitations around what can be done though. Pretty sure auditing in bulk could be done via Dynamo in any case though.

I’d be happy just to know what package and version the node came from. Not all packages are on the package manager so any kind of automatic download will come unstuck at some point. Currently I use John’s tool for labelling nodes in my 2.0 stuff which ticks the box for now.


Automatic Download is never going to fly, for any company with any serious IT department and security mindedness. But solving the Package DISTRIBUTION is a whole different animal than just solving the Package Requirement notification, which (as Keith said), Monocle does a kickass job of.

Honestly, Dynamo doing exactly what Monocle does, automatically and on the fly, would be badass. Providing both- a list of packages needed (which Monocle it does now) and annotating the nodes individually (which Monocle does now).


Excellent question! The current behavior is that only top-level dependencies are listed, packages depending on packages can be solved by the one click magic download button. If you open the corresponding dyf in dyn, you will also see the dyf package dependencies listed on the right. But I assume you mean you would like to display all dependencies once dyn is opened?

1 Like

Sure, once we finished gathering feedback of this extension, element binding surfacing is also in our radar.

1 Like
  1. This would be great! I always have to figure out which package and what version when I look at a workflow from someone else.
  2. Yes Temp download or option for new full version download permanent install.
    Keep up with the great ideas!

I think that the idea of automatic downloading of package for single users is great!

But for companies as @aaron_maller said would be a much greater issue.

Anyway, keep up with the idea!

1 Like

‘unravel’ code when you bring it in- OR- maintain a library of Dependencies.

Unraveling and importing has a few effects-

  1. The code is stable and non-dependent.
  2. You can parse out unnecessary junk you don’t need (Including editing python and other nodes)

This is why I advocate for ALL ‘support nodes’ to NOT be compiled into one touch nodes. If it is all open source and we can validate and dissect and reintegrate it - we end up with better code.

However - IF you want to go the length to maintain repositories - keep in mind as users develop nodes that don’t conform to a rigid syntax- functionality may change or complete deprecate content from one version to another (Again why I recommend unraveling content)


This feature is much needed and would work great in a stable revit dynamo environment.

This would be beneficial for getting packages that are DLL based. Packages with dyf files as nodes might be modified by user A during development, and when dynamo installs the missing package for user B (from package manager), graphs might not work even when the suggested tool says that user B has everything installed. (Unless somehow the dynamo team can track those too :)).

To add to @john_pierson suggestion, you guys could do something similar to what pipenv does for a python environment, creates a lock/reference file and maintains dependency versions.

I would recommend against auto-download feature: revit, dynamo, python, packages environments are hard to track as it is.

Another approach could be to add a tool to dynamo to bundle-up everything needed, together at user A machine, when sharing a graph with user B? much like a .exe file does? Although this procedure would have similar risks and drawbacks too.

Any of these methods are a potential security risk. Especially considering most users of this proposed feature would be the most vulnerable (because of lack of information).


It’s not really my place to comment on Dynamo any more, but I think it’s pretty important that I give a little history and make a recommendation.

When we started building the Package Manager many years ago, we looked around at existing technologies that we could repurpose. At the time, Sublime Text packages were built using git repositories, which we thought was cool, but we didn’t think anybody in AEC knew what GitHub was. NuGet existed, but wasn’t owned by Microsoft, and wasn’t nearly as fully featured as it is today. So we decided to build something unique with the assumption that we’d rip it out and use something else when it came along.

If I was rebuilding the Package Manager today, I probably wouldn’t. Package management systems have come so far that attempting to solve the number of problems embedded in PM systems whilst also trying to build Dynamo is just too much. I would strongly suggest that the Dynamo team investigate building a thin layer, if even that is required, on top of something like NuGet or Chocolatey. NuGet allows not only dependency management for .net assemblies, but also arbitrary content files. You could pack Python scripts, dyf files, and help files into a NuGet package’s content folders. And Chocolatey is less .net package specific still. I do a little poll whenever talk to architects now where I ask, “how many of you know what GitHub is?” And I’ll tell you, in 6 years that number has climbed from zero to pretty much everyone. You could do like Go, and build the next version of the package manager on git repos. Granted, git is not a package management system, you’d have to handle versioning through branches, tags, or other git mechanisms, but you get discoverability, storage, and documentation for “free” in a way that software is actually being developed today.

By thinking through the problem of utilizing an existing package manager, you could also start to tie Dynamo into larger ecosystems of tools that are available, which you can’t right now because Dynamo packages are something “else”. The bespoke nature of the Dynamo Package manager has negatively impacted its pace of development over the years, and I’d like nothing more than to see the sharing of Dynamo packages be able to explode on the back of technology the Dynamo team doesn’t have to build.


Yes, i assume something like that.

But still ok if we open the dyf file at least from there we will know the needed packages for the code.

This will be a great update.

1 Like

Nice initiative.

  1. It does sounds like the missing piece of a puzzle
  2. Propose ways to fix it with explicit explaination: older version or newer version of a package, API change… , dll not loaded, local node not loaded, etc.
  3. I like @ikeough idea to change the Package Manager architecture to a Github with a coating :cake:
1 Like

This might be a great extension for individuals or small teams but thinking of corporate IT this would potentially create a real mess. Loss of consistent installations, busted graphs, yet lesser documentation or traceable performance of graphs.
But then, our corporate IT doesn’t even let Package Manager do what it should do…

1 Like

I echo the sentiments against downloading anything automatically. Most IT environments have different ports closed that could potentially wreak havoc on a solution like that.

How about a simple utility to “pack and go” the Dyn file and any custom nodes that are used in it. I think this would go a long way toward making scripts truly shareable. This could either make an executable file that unpacks the custom nodes into the required folders, or you embed the node definitions right into the Dyn, or invent a variant to the Dyn that can contain nodes (Maybe call it Dyz for Dynamo Zipped).

When you develop scripts on your computer and then need to share them, it is always a hassle to have to document what custom packages were used, and have everyone install the same ones. What if they have a newer version of those packages? What if some of their own scripts require the newer versions of those packages, and they break after installing an older or newer package to make your script work? The ability to share packages on a network falls apart because you can’t share DLLs, which most newer packages are built around.


Hi All,

Maybe a bit off topic, but have you tried the Dynamo Extension DynaHub by @andreatas ?

It’s open source and it has lot’s of potential. You can download graphs and packages in one go.
Never have missing dependencies.

What to do you think?

1 Like

I think the sample would be a great improvement.

On a similar topic- I think it would be improvement to the UI if it was easier to see which package a node was from, and which version.

Even if you have the package installed- to see which package a node is from, you need to RMC and look in ‘help’ Perhaps the package could go into the node title e.g. MeshToolkit.Mesh.Sphere

Finding which package version you have is in a separate spot i.e. in package manager.
Can the version go in the node ‘help’ ?


I think managing dependencies is critical to development so I think this a great idea to help hunt them down if they are missing.

1 Like

I have not! Do you happen to have a blog post or any article explaining it?

Glad you raised this, this issue has been bothering me personally as well. Identifying nodes from host or nodes from package is a general challenge. I may expand separate post on this, but since we are here, do you prefer node help than other places like right side panel? Or you do not care as long as it is easy to find out.