Hello,
We have been working on developing a number of Dynamo scripts that resemble a kind of toolbox for architects in the design phase.
As these scripts are not yet fully functional, we are considering deploying them within our organization: users spread over several sites with laptops or fixed PCs with the ability to work remotely via a VPN and access a shared directory.
What would be the most efficient and simple way to manage the packages?
We had thought of using a shared central directory where users could copy/paste without question the entire directory to their own machines; the idea being to not clutter the architects’ heads with the technical management of the packages because they are only users of Dynamo Player.
But it seems to me that this way of doing things is not very robust? Does it ensure that all users have the same set of packages that the script developers used.
A bit of a rabbit hole this question as lots of ways to approach it and is quite relative to how you intend for people to use/interact with Dynamo.
As you’ve indicated it will likely be people without knowledge of the software simply ‘hitting play’ in Dynamo player is is probably best you centralise them somewhere on the shared system rather than try to get users to install a list of package.
Things to consider using this method:
Make sure you are aware of the different versions of Dynamo that people are using as some packages are not yet compatible with the latest versions. You might need 2 folders relative to which version of Revit (and therefore Dynamo) people will be using. I would also recommend testing each of your scripts in all of the environment options the users could be in.
If you are copying the whole directory into a shared folder most of the time you should have no issues and yes other users will be able to see the same packages you will. Just be aware that some packages with direct downloads outside of the package manager sometimes don’t transfer well by simply copying directory contents (I’ve had issues trying to deploy Orchid centrally for example).
Write access to the shared location should be considered so that only certain users can edit packages in the allocated location (You don’t want someone deleting a package and invalidating a load of scripts).
If you’re not already - Use the Data-Shapes package with its UI nodes for simplifying the script inputs for users through Dynamo Player.
Consider using an external package management tool, Github has a subscription service and there are a few open-source ones knocking around but im not sure about the compatibility of any of these with a Dynamo workflow (not sure if anyone else has more knowledge here?)
Don’t use a shared network directory for your Packages. Mirror it locally from a network folder you manage. Using the shared folder will give you errors with multiple people accessing the same .dlls at roughly the same time.
Also, if you go the Dynamo Player route, are using R2019 and you are not using Dynamo 1.3 make sure it is actually uninstalled everywhere, since it will be installed by default with the Revit 2019 install and updates. The player might fire up 1.3 and run your 2.x script with it resulting in an error.
Interesting, hadnt thought about that. Maybe we dont have enough users yet that this is an issue. What sort of errors would you expect to see? Would it sit idle waiting for the dlls to become available or simply not run?
Say you deviate from the shared directory in favour of mirroring like you said, how would you go about updating 50+ users package directories when downloading/updating a new pacakge if you do not have macro / IT capabilities ?
If you just want to mirror the folder there are several lightweight windows/network admin apps that can do that for you. I’m in the position that I have acces to a capable IT department that just said they would take care of it once I explained what/why we needed. So I don’t know what they went with in the end.
The end setup is now that we have a folder on the network that I control and get’s pushed to the users on local network login. That local folder is pathed in the Dynamo settings as the package path.
What you will see with regards to errors is package Nodes not being loaded, so the scripts are failing on them. I think it will turn them Red and give you a Not Resolved status.
As much as I would love to say my solution was the right one, @Bjorn_Keulemans1 made some very valid points.
I have since directed the package management strategy of the company I work for away from a shared, network-hosted package directory towards an individual C: drive rollout of packages from a central location to each user’s relevant appdata/Dynamo/version/packages location.
Probably would be best if the solution should be given to Bjorn, not myself. My conscience isn’t clean with an improper solution on my profile haha.
Create a document showing the packages typically required. Make sure everyone has monocle installed. Then when a package is missing or out of date, they can just updated via monocle.
Monocle also had a simplified search which is very good. Access it with CTRL+F.
Do not distribute on a network to a pointed path. Not good.
You could however create a script to copy packages from a network path to local drives…but I would still recommend monocle. It really is great.
Have a look to NonicaTab PRO in the Autodesk App Store! It handles all your packages automaticaly and allows you to integrate and deploy Dynamo scripts as Revit buttons.
It handles all your packages automaticaly and allows you to integrate and deploy Dynamo scripts as Revit buttons.