Lifting python code out of custom package nodes?

Packages
6

This just kicks the problem down the line. Eventually ALL of that python will need to be updated for a new version/API change/whatever breaks the current code. There is no such thing as code which doesn’t have to change - even the calculator in windows is drastically different underneath than it was back in 1993.

When that change is forced, you now have to open EVERY SINGLE GRAPH with python in it, do a save as to get a new .dyn, and edit the Python to work with the new environment. Then you have to make sure that users point at the right .dyn for their environment (ie: a 2021 user should point at the graph for 2021, etc.). And they have to always go to the right version, unlike packages which are ‘set once and forget’.

Beyond that, every python node will have to be edited for the particular lacing strategy of the situation. If the graph worked with one list of doors, but now you want it to process a list of doors and a list of windows you’re writing new code (and now you have 101 graphs to deal with). And that issue with ‘two lists’ will require specialist knowledge (likely that only you have) of list handling in Python to fix, not a random Dynamo user who could just check “@L2” on the node.

Lastly, you can’t address zero touch nodes this way, which means the following packages can’t be used in your environment:

  • Rhythm
  • Archi-Lab
  • MeshToolkit
  • Pattern toolkit
  • Dynamo Text
    *Refinery Toolkit
  • Civil 3D Toolkit
  • Camber

That list includes some really heavy hitters… Basically 4 of the top 8 packages for Revit aren’t viable, the three top packages for Civil 3D, and most of the top packages for Generative Design are no-goes for your org in perpetuity until you teach all your users how to leverage the package manager, or you start configuring their environments.

Instead, I recommend you deploy the packages just like you deploy other content.

  1. Build a ‘source’ directory of packages for each environment you have (one for Revit 2021, one for 2022, one for 2023, one for 2024, one for Civil 3D 2021, 2022…)
  2. Utilize Robocopy, Group Policy Login, Installers, or other ‘push’ techniques to shift content onto user’s systems.
  3. Provide a ‘hot link’ to allow updating the content in their packages directory on demand.
  4. Build one directory of graphs built to work with the packages deployed in any given environment.
1 Like