I’ve found a few topics similar to my question but I’m still a little confused. I built 3 scripts last week with the help of the good people here. I shared with a friend and ended up walking him through downloading all the packages that I used. This was extremely clunky, as he has never used Dynamo before and it ended up taking an hour and a half to do this. Shouldn’t there be a way to package and share a script in the same way that we can share Projects in Revit for example? Like if I share a project, I don’t have to share all the families I used in it. Shouldn’t there be a way (or is there) to send the file and the nodes that are used are sent with it? Or, alternatively, what is the best way to handle this issue if the above is not possible?
Try not to rely on package too much, try to code the script yourself. Packages have versioning problem too.
Some packages you can explode the code and see what is inside and modify it yourself e.g. clockwork
This just shifts the problem from the user getting the package, to you maintaining and updating the code for every single graph you deploy. Packages are far simpler to maintain and deploy at scale.
Note that with newer builds (about Revit 2022 and on) the workspace dependencies manager should make getting the right package fairly straight forward, letting the user know what they need to install if it’s not already there.
In addition to the suggestion by Jacob, consider a solution like Orkestra. Whilst paid, it is probably the only scaled system out there that doesn’t depend on IT support to get packages and versions managed across user machines.
There are ways to make Python code scalable as well if you develop your code in libraries and append/import them to your Python nodes when needed, but Jacob is right that it can be a fairly high technical debt depending how you manage it in that case.
As a midway point to @newshunhk’s suggestion, do be considerate of how many packages you depend upon. Try to keep it to large/supported packages where possible and avoid packages not updated in a long time in most cases (e.g. SteamNodes, a common query generator on the forums due to deprecated input structure).
Personally, I gave up. No packages. Ever.
Just went to doing everything in Python and am headed back to VB ad C.
I like to use Dynamo as a development tool, but all I’m doing is one python script inside the DYN. Once get it all working - out to just a *.py file. Deployment is via pyRevit which requires no admin rights or complex installation. Things run faster.
Any old or small widgets I made in dyn are also managed in pyRevit since it really doesn’t care if the script is dyn, py, vs, or cs
The only time I’ll do a dedicated dyn is if there is some geometry heavy lifting that Dynamo is particularly good at. For instance, my AutoCAD style Pline tools.
Thank you guys for the replies. Pretty unfortunate that a script can’t be shared and opened by other users like almost any other file that we use these days.
The script that I wrote specifically was to renumber views in Revit. I don’t know if the nodes that I would have needed exist in the OOTB packages. I’m super green in terms of Dynamo. I know what I want Revit to do then come here to request help after many failed attempts usually. So the script that I wrote was mostly provided by another user (from a very old post) here on the forum.
In case anyone is interested in what I actually did (I’m sure that some of you could glance at this and know if it could all be done natively in Dynamo without additional packages or not) here is a screenshot and the actual script is attached as well.
Detail Renumber.dyn (22.1 KB)
You can always send the packages you used with the DYN so that the new user has everything needed. The issue is more around sending a DYN to someone who doesn’t and hasn’t used Dynamo before and expecting them to just run your graph and be fine. Most users with minor even minor experience with Dynamo will probably already have a lot of the packages required or will know how to get them. Same goes for not yet understanding how to write graphs without the need for tons of (usually) unnecessary dependencies.
One trick you can use for sharing graphs in older versions (I wanna say around 2021 or 2022 and older) is to save the graph as a Generative Design graph. This will automatically create a graph dependencies folder for you. This is a quick and easy way to get everything you need to run your graph. That being said, it doesn’t replace the need to understand how to best author your graphs for sharing and minimizing dependencies.
I can’t see it’s such a big deal.
Use monocle package use doge and make sure you label each node that’s not OOTB.
Also make a list in the script of the packages required (also package use doge)
As long as you’re not using 100 packages it’s not such a big deal.
Each package only takes a short time to download!
If there’s just 1 node you use regularly from a package then yes, make it yourself but otherwise… use the package!
I always colour code my scripts, always have a “packages used” section and label each node that isn’t OOTB. Not had any issues.
Also worth adding a list of packages that are pretty reliable and well maintained that are worth looking into:
Archilab (lots of general utility, mostly ZT)
Bimorph Nodes (some utility, good intersection nodes, mostly ZT)
Clockwork (lots of general utility, mostly Python)
Crumple (my package, I’m biased, mostly Python)
Data Shapes (user interfaces)
DSIronPython2.7 (needed to run most Python packages in 2023+)
Genius Loci (lots of general utility, mostly Python)
MEPover (nodes for MEP engineers, mostly Python)
Monocle (Dynamo workspace utility)
Orchid (families, requires an exe installer)
Rhythm (lots of general utility, mostly ZT)
Spring Nodes (lots of geometry utility, mostly Python)
Whilst I don’t recommend using them all at once, they’re usually a safe bet for reliable outcomes and provide enough utility to warrant their use in a company that can distribute packages to users.
I’d say that could be a bit misleading.
There are loads of packages that are reliable and not one size fits all.
I’ve had issues with at least 1 of those packages you’ve mentioned.
It’s a better metric to see the numbers when you download than a single post on here.
Of course, I just mainly give people that list in order to try them out. Better that than gambling on the package names as a newer user.
At the end of the day Alien’s right, you’ll find the ones that suit your needs and that of your company (if any). The list I’ve provided is quite tilted towards architecture (e.g. it has no structural packages), as well as Revit (Civil 3D not included, but for that I’d look into Camber).