aka Dynamo Package Best Practices
As you all may know, I have published a few Dynamo packages. Over this time, I have learned a few things that have helped me keep most of my sanity while managing these packages.
While preparing to publish the package, Sean asked me if there were any “gotchas” that I had run into over the years.
After speaking with Sean, he pushed me to share it with other aspiring package creators.
So here it is, my “Dynamo Package Publishing Checklist.” (Remember this is not an absolute go-by or absolute truth.)
Dynamo Package Publishing Checklist
- Build with no dependencies on package manager-based packages. Dynamo handles these very poorly, and it creates a terrible end-user experience. Note: This is not the case if you are sharing a workflow (DYN) bundled as a DYF that you want the person to be able to get the dependencies for.
- Publish your Dynamo package with an email that you plan on having access to for the foreseeable future. Gmail is forever; work emails are not. Note: This has become more difficult recently with Autodesk SSO. You cannot simply log in to another account, and all is well. If you are running into these issues, you can contact the Dynamo team directly to set up multiple emails to manage a package.
- Versioning is very important. Decide on it upfront because it does matter. There are several ways to do this. A few of the most popular are:
- Semantic Versioning 2.0.0Calendar Versioning > I use calendar versioning for Dynamo packages. If I published a version of Rhythm on Feb 2, 2021, it would be v.2021.2.1. It is my first release of Rhythm this month of this year. 2021 is the year, 2 is the month, and 1 is the patch number (not the day of the month as it may seem).
- For Zero-Touch Developers: Never bundle DLLs in your package that the host software already loads. This includes items like the RevitAPI or any of the Dynamo DLLs. This will raise all sorts of errors in Dynamo and can result in crashes.