I have created a .dyn module using custom nodes. Is there a way to embed these nodes into the dyn package ready for distribution? Unfortunately I cannot avoid using the custom nodes. Distributing Clockwork was painful enough for a client behind a tight firewall (blocking access to the Package Manager), I don’t want to go through that every time I deliver a module using nodes from a different package.
If you don’t want to worry about dependent packages you can “unwrap” the custom node. Most of the standard, everyday custom nodes are just nice wrappers for a few OotB nodes or a Python script. Use the “pieces” instead of the custom node itself.
This does become a little tricky if you have custom nodes wrapped inside custom nodes, but you’ll probably be able to avoid those scenarios a good chunk of the time.
There has to be a way to get around that. What I do is supply a zip file with the packages used and a thorough explanation of what is required of the workflow,(PDF and video). I also list which versions of Revit, Dynamo and packages I used to be completely clear.
If Dynamo is your deliverable, it is important to make it as understandable as possible.
This is one of the considerations needed with Dynamo. But with that consideration, we get faster results with Dynamo because of the great community building stuff. The other option would be actual Revit addins which results in a considerable fee bump.
I realize that does not “solve” your problem, but I hope that should help either way.
Own wait code block! Excellent. I think unwrapping will be a good medium term solution. Long term it would be ideal to have the option to self contain everything, this would make it easier for end users and everyone. Thank you all for your help.
Long term that would also delay development for the community and your own work as everything would have to be self developed as well.
Producing a zip file as @john_pierson described above is likely your best bet short term for other packages which can’t be code blocked directly. Long term teaching the clients the value of allowing packages and other aspects of Dynamo within their ecosystem is the best possible solution. Fear of packages, scripts, and software causing them to try and build a ‘walled off garden’ will lead to their missing out on the next step of the digital revolution in the AEC industry (generative and computational design).
@Yna_Db and I have developed a script to tell you what packages a file uses. After you write your script you can run this script and it will tell you what Packages you need to package and send out with your script. This way you can make sure you did not miss one. Yna_Db has greatly improved upon my initial script but it does still need some work with the Zerotouch nodes. Hopefully this will be solved soon.
I should have originally mentioned that unwrapping a custom node only works in situations where lacing is not an issue. That’s why I specifically mentioned the “basic” custom nodes that everyone uses for minor boosts in efficiency, complex functions (that aren’t in Python) will likely have trouble here.
Wait or Passthrough nodes work by ensuring that one part of a graph has completed before starting another part. A simple way to do this is to combine these two parts in a list.
Wait is the final output of Part 1 and pass is the first input of Part Two. Creating a list out is the part that ensures where/when your transaction starts. Out cannot be created until Part 1 has completed and wait has a value. Then you simply return out, your passthrough value, and the graph begins Part 2. Wait can still be any value, even null or empty, it just has to run.
To put a point on this: this is exchanging the technical debt of managing and documenting the packages used in favor for becoming the owner and maintainer of that code in perpetuity. Don’t set yourself up for long term pain because of a desire to over simplify a process which can be managed by individual users or at an enterprise level.
100% agree. I’ve helped out a few clients with so many dumped Python bodies from custom nodes, it makes the result a huge pain to navigate for the end user and ultimately puts them off Dynamo itself.
John’s initial advice was spot on from a consulting perspective. Teach your client or end user about package installation and alternative methods (manual copy/paste folders etc.) if the firewalls are an issue. What they will get is a better surface understanding of Dynamo and dependencies, rather than a bunch of Python script they can’t interact with should their curiosity in learning about Dynamo develop.
The dependency manager and such packages as Monocle really help in guiding users to the right custom packages to supply, and I’ve found at a company level if you standardize the packages and their builds it’s super simple to manage their deployment via having IT write and supply batch scripts to copy the needed packages the company will use from server to user folders.
I’ll also add that with the new extensions this is practically handled for you. Generative Design even wraps everything up for you in a folder for sharing. Would be nice to see that extended to vanilla graphs as well.