Dear Dynamo developers and users,
Here I am again! First thanks for sharing your idea to our Dynamo developer team in my earlier post [Request for Feedback] Extensions on Dynamo Right Side Panel. Your feedback is very well received and should help to guide our next series of development using the new area on the right. As a result, the work of right side extension panel in Dynamo has been merged in master branch and available now for people to take a peek in 2.3.0 sandbox daily builds at dynamobuilds.com.
Today I am going to showcase a sample view extension our team is working on using this idea. Below is a gif illustrating a user workflow where user B downloaded this graph online from user A and open it locally. The Dynamo package dependency information of this graph is displayed on the right panel because user B does not have certain packages installed (as you can see there are nodes in warning/error state because the corresponding packages not install or loaded locally). Our team found this workflow has been blocking lots of users since it was so difficult to know these hidden info despite the graph author and often times users will have to contact author right away to be unblocked. Our team would love to start making this info more transparent by displaying it when it makes sense in a future version of Dynamo. Please see gif below for preview of our teamâs work. Notice packages in red means they are missing while graph open.
And now we kindly need your feedback from here
- Does this sounds/looks like the missing piece you have been looking for during Dynamo graph sharing?
- Maybe our team should add a magic download button to download all the missing packages?
- If this does not make sense to you, can you suggest an ideal workflow in your mind?
- Any comments are welcome here and I will be watching this post!
Thanks for paying attention and giving us feedback.
Aaron
Progress updates (as of Dynamo 2.5 daily builds):
As I mentioned in comments:
Currently we have encountered four cases, as some of these cases are covered by the comments in this thread (tremendously helpful). Please also give us comments if any of the message does not sound proper to you or you have feedback on UI side.
- 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 and need graph authorâs attention
- Package Dependency is not installed locally, but some or all of its dependent nodes are resolved by a different local package.TBD
- Package Dependency has been changed and is awaiting a restart of Dynamo (so that dummy nodes can be resolved)
23 Likes
Do you think it is possible to download not the whole missing packages and instead just download temporary the missing nodes in the graph and deleting them after closing the script? My Dynamo node search gets really slow, if I have many packages active.
This is a sorely needed feature that a lot of people will welcome!
How do you handle cases where a package is not missing but is a lower version than the one used to generate the graph? Maybe you could display such cases in orange and have an update button too.
How about the reverse case? Sometimes as packages evolve, nodes get depreciated. Should there be a warning, if letâs say the graphâs package dependency is very old relative to the current version thats on the package manager?
9 Likes
very good questions @Dimitar_Venkov - I think in the current PR - the âmissingâ condition is triggered by anything except an exact match. The most robust packages do a great job of keeping up compatibility between releases, but there are many packages that do not. We could use sem-var to guess, but that only is useful if package authors use it.
How does it handle, say Archilab and Rhythm, which does a great job of handling the many versions?
What if a package isnât on package manager?
Does this address calls to methods which are not available in the current environment (say open a Ynamo for Revit graph in Sandbox). Those are OOTB nodes so there is no package, but it would help a growing number of users if a warning came up which said âyou need to be in Dynamo for Revit to use Select Faceâ as one example.
3 Likes
A new user here, but here is my user feedback:
- I believe this feature will definitely work for many, sharing scripts is not as easy as it should be at the moment cause of all the nodes someone could be missing.
- This will be obviously be the most perfect solution, but probably also a difficult one to pull off properly for the team? Maybe release the one in the example first and later on âthe magic buttonâ
- No idea, this seems like a good solution.
Good luck!
Regardless of scope (previous versions, deprications, environment, etc) this would be extremely helpful for a number of obvious reasons. Very excited about this.
1 Like
-This does sound like the missing piece we have been looking for. I know that when I share graphs with my team internally, these issues still come up.
-The magic download button would be nice (But you need to have the word "magic in the label ;))
-This makes perfect sense to me
2 Likes
@Thomas3 Interesting, I have never thought about this. I believe making stuff temporary and uninstalled after current session might be possible but from the current mechanism, temporary nodes will all be loaded in search candidates and will be hard to distinguish them or skip them. Our team will give it some more thoughts.
4 Likes
This would definitely be an awesome addition.
Just out of curiosity : does this mean that package information will be serialized in the dyn files?
1 Like
Will it be able to determine the node package used inside a dyf node?
Coz, in our case, we list down the package dependencies of our dyn files so other users will know what packages are they missing.
Sometimes, we end up missing out the nodes inside those custom nodes/dyf nodes.
1 Like
The data about which packages are used will be saved inside the .dyn as a hashed string, similar to what you see with element binding.
Temporary packages will be a no-go for most enterprise customers (IT and info sec would flip), in fact I would recommend against any form of automated downloads. From a security standpoint, users should have to click through for each package in use.
2 Likes
It would also be difficult I imagine as more and more packages become ZeroTouch and contained in one DLL.
2 Likes
Iâm sorry, I think that option sucks. If you guys are going to add this to Dynamo, please donât hide it in the same way as element binding, (which a lot of users constantly struggle with BTW). If that is in fact the route it goes, I can safely say I will not be recommending this as an option to any of my clients/users.
Better use case
Make it something user-understandable. Right Click > Edit DYN with Notepad++ > âOh look I need the following packagesâ. Or even better, you can build batch tools to look at all the DYNs at your firm and get an itemized list per DYN.
15 Likes
I am just a user and another thing happening in the background like element binding is not good. I like the idea of a right click to download packages
2 Likes
Right click to download will still be there.
1 Like
I may have spoken to quickly on the hashing aspect, but the intent would be to save the data in the file.
1 Like
