Best practices to aid non-dynamo savvy users to use custom packages in dynamo player?

To this wonderful community,

I am attempting to enlighten the end-users with the power of Dynamo Player. I am the only dynamo-savvy-python-person in my office. The issue i’m having is that some of my graphs use custom packages (clockwork, springs, etc…), and the end-user does not have the time to learn how to install custom packages from the package manager.

How can I incorporate custom nodes into my graphs so that the end-user does not have to install each required package?

I am aware that some of the custom nodes are python scripts, which can be copied and quickly remade into a graph, but that doesn’t seem to give the author’s the credit they deserve. Is there a more ethical way to go about this?

I have encouraged them to learn the basics of Dynamo, but I have yet to avail in this effort.

Thank you for reading this and I look forward to any suggestions!

2 Likes

I know you can set up a network location for packages, so that anybody using that path will automatically have the relevant packages loaded. I think you’ll still have to manually set the location for the network package directory for each user though. (the Philadelphia Dynamo User Group had a speaker cover this a while back. Check out the video here: https://youtu.be/b8uHvBnVS34?t=6831 )

Perhaps there is some way to run a .bat that would set up this location for each user, but others more knowledgeable than me would have to weigh in on that.

6 Likes

@djhballinger Thank you for the suggestion. I like the idea of the network location; just not having to do it for each individual user.

I’ll check out the video.

2 Likes

An update:

I learned from @john_pierson at #AU2022 that referencing dynamo packages from a network location is a bad idea (if drive size is over 100gb, which most network drives are). This is a known issue from at least Dynamo 2.0, and tends to cause Dynamo run slowly.

If you have a way to manage deployments through your IT group, it may be worth it to have a central location to store packages, and a regular updater script that copies these to each users local drive. Then you can reference the packages from there.

1 Like

Indeed it is.

Personally where I work (about 25-100 Dynamo runs a day on live projects, 400+ people overall, about 40% on tools) I bit the bullet and just wrote everything in Python. I use a custom package to store my starter nodes, then lift out the Python and go from there.

When Revit 2023 swung around it gave us three choices due to IronPython2.7 deprecation:

  • Build two copies of each script, one for 2023 onwards
  • Have users install the DSIronPython2.7 package (custom package), or get IT to deploy
  • Don’t rely on Dynamo at company scale for 2023 onwards

I settled on option 3 and moved to pyRevit which we now deploy across company machines, although we did consider deploying DSIronPython2.7 for a while. So far no regrets, and we still use company wide scripts for 2020-2022, but users know come 2023 Dynamo hangs its hat up beyond project specific scripting unfortunately. I expect within about half a year pyRevit will overtake Dynamos run count since I started tracking in 2021, and I began deploying it earlier this year for users.

Hope that gives some context from a large company perspective.

2 Likes

Wow thats sad to read. just started to get the hang of Dynamo heh…
Fortunately for me Python is the first language i started learning so all the more reason to focus on Python for me…

Oh I use it all the time for project specific scenarios or those with limited scale, but at major scale I need cross version compatibility and there aren’t enough hours in the day to build/maintain a script twice over. Dynamo is still for me the perfect gateway into programming for AEC.

I think with enough layers of IT support and middle managers it can work, maybe with Orkestra as well, but to do it manually and assume R24, R25 wont introduce even more compatibility barriers isn’t worth the risk for me at this point.

2 Likes

@moore.spencer John Pierson also wrote an article on this topic of deployment for the Dynamo Blog this month. How to Deploy Dynamo Packages Easily - Dynamo BIM

2 Likes

I utilize a third party plugin. Either orkestra or nonicatabpro. They have associated costs but are well worth it. orkestra with it’s dev tools like okpy and node snippets pays for itself in saved time easily.

My firm has a shared file location where our Dynamo developers place all the packages they use, these get copied to the designated package path folder on the users C drive on log in when our server notices a difference between the shared network folder and local folder.

3 Likes

Our approach is similar, but users have to manually copy the shared folder to their local folder.
Somehow this doesn’t work for every user though. Sometimes the Packages don’t show up in Dynamo
and have to be installed through Dynamo, but this too cause problems from time to time (conflict with already installed packages) :unamused:.

PS
When people at my office try to download a package from Dynamo Packages they sometimes get this error.

image

Is this error on our end of the sites end? Does anyone know?

Perhaps your IT system is very strict?
I think this could be caused by not having writing permission for example

Yes, out system is kinda strict, but when someone tries 5 minutes later the file can be download.
When someone gets this error then packages can’t be installed through Dynamo as well.
I think the problem is on our end, but just want to make sure.

If it doesn’t happen consistently that to me would indicate it’s an issue with the network, as this is the most likely service to act unpredictably.