Packages allow more coding literate people to provide us with enabling tools through nodes.
My issue lies with updates. Yes they might do a package much more awesome but some nodes which are critical to workflows created, as the package gets updated they are deleted or the input/output changes.
That brings me to my question: Its not currently possible to have 2 versions of the same package on your workspace loaded. Why?
How can I get around that issue?
Use only outdated packages for one awesome node while missing out on updates?
Would anyone know if its possible to have two versions of the same package? (Obviously i tried different name folder on the Roaming file)
The issue you outline is exactly why I will not use any package node as part of a critical workflow. Instead- I use packages as educational software (great for learning - but not for production). This means that if I want to use a package node for one of my tools that is saved as a workflow for repetition use by many people, I must first force myself to learn and understand how that node accomplishes its task, then I re-create that functionality myself using Core nodes and Python (which I did not know before I learned Dynamo - guess how I learned - reading other’s python inside their custom Nodes). Short term, it limited my capabilities, but long term I learned a lot that helps me daily, and all the Workflows I’ve made for my firm are much more stable due to no Package dependency.
3 Likes
You are right Ben. But then other factors come in, such time time vs professional value in a GC that the Cad deptm is me and a CAD engineer.
Anyway I would appreciate any sources to help me on my journey?
Seen couple of custom nodes. The terminology is Python specific or Revit API specific?
Thanks.
Regards,
john
Well, this is what @Ian_Keough1 had to say about packages. Clearly then, you should probably jump into the mix - maybe even publish your own package - or you can stand still while the rest of the Dynamo user-base passes you by doing awesome things only packages enable.
Look at Kangaroo for Grasshopper, or: Archi-lab, SpringNodes, Clockwork, Rhythm etc for Dynamo, the list is growing, and its these packages that are opening up the API (which is huge, and which the Dynamo team wouldn’t be able to expose without the support of the open source community) for those without programming skills who are then able to do things which would otherwise elude them:
Here’s what I think should happen with regards to packages [= 3rd party apps FYI]. There should be more stuff moved out of of our core distribution and distributed as packages, including our Excel functionality. The problem is that packages have been treated for some time as second class citizens. Packages should be the primary mechanism by which we deliver new functionality for Dynamo…packages are a much better organized and modular way to deliver software than us bloating the Dynamo install with a zillion dlls in the core folder. And they allow you to deliver documentation, examples files, and other assets in an organized way.
Sure, there’s a lot of crap that gets published, but the number of downloads is a good shortcut to establish which packages are most useful (and also well maintained).
4 Likes
True. Basic stuff such as parameter management etc are sufficiently covered by the core nodes.
Now if you are looking to innovate and move over the out of the box software given to you, at least basic understanding of script behind the tools is essential (reiterating it to myself really).
If you have a critical workflow and want to leverage a static package due to concerns of future updates, just store that package in a separate location with any related files. Then ensure you are pathing only to that location when using that workflow.
In summary you can have project specific workflows supported by project specific packages minimizing concerns of users having incompatibilities with later package versions.
If you want to leverage updated packages on other workflows just path to the location of the later version.
My one big misgiving with packages is that they are primarily sole-sourced, and life happens. That guy that built that awesome package and maintained it well for a few years, what happens when he gets promoted to a role that affords him less time to dedicate to the package maintenance? Or he has a kid and decides that is more important? Or he has some tradgedy, illness, etc? Dynamo Core has a team behind it, thus the product will go on in spite of individuals leaving. If Andreas or Dimitar or Konrad were to walk away from it all tomorrow, where does that leave everyone that depends so highly on their work? I’m not just trying to be contrary - I really want to know if that is something we should be concerned about, or am I just overly cautious?
3 Likes
Its open source…the answer to your question then, is the rest of the Dynamo community! Dynamo doesn’t hinge on a handful of talented people! In fact, it should spur you on to learn modern techniques to design realisation, namely, coding.
2 Likes
That is the hope for sure, the community has the tools to pick up where others leave off.
I wrote my first response to the OP to show other options. If we are dependent on other freelancers for stuff that is critical to our paid work, we cannot be sad, frustrated or angry if they drop the work, change things, etc. If someone feels that packages are a risk or an Achilles Heel, there are other options besides using packages. They are a convenience, but not without risk (relatively low risk, but risk nonetheless). But packages to provide a great source of educational content that can be used to grow your own skill sets so that if the time comes where you need to contribute, you have the tools and knowledge to do so. The danger is that too many will simply “use” packages without ever understanding how/why it works, and the community will be less knowledge-rich than it could have been and thereby dependent on the contributions of a few key people and unable to function without their contributions.
2 Likes
How can I repath the location for specific workflows?
How can I make it different to Roaming-> packages path?
Fair point Ben, thats the point of this thread…
Looking back at the past four years working with Dynamo, I would say that the majority of changes in my existing workflows were due to changes in the built-in nodes, not due to changes in custom nodes. Upgrading to 1.2 has shown that again with the new list@level features making some built-in nodes superfluous in most graphs (e.g. List.Map, List.Combine etc.).
Personally, I don’t think there’s any way around using packages. I don’t think I have a single graph that does not contain a custom node. Dynamo provides a great infrastructure, but the Revit API is so vast that I don’t expect to see even half of it being available as built-in nodes in the foreseeable future.
Also, as a package developer, I strive to introduce as few changes as possible that break existing workflows (because it also affects my own workflows). Additionally, Clockwork and SpringNodes both have documentation about deprecated nodes and what to use instead (see below). Not sure how this is handled by other packages, though.
4 Likes
Settings-Manage Node And Package Paths