We’re excited to announce our latest release, Dynamo Core 3.4 !
Check out a quick blurb below:
Dynamo Core 3.4 includes the following highlights: The Install button in Package Manager defaults to a package version that’s compatible with your setup thanks to new author-assigned version compatibility information. Authors can assign this info on the updated Package Manager website. TuneUp is available as a built-in package and includes more improvements. Mesh Toolkit nodes are included as a built-in library under Geometry > Meshes > Mesh. A new Python engine called PythonNet3 is available on the Package Manager. This release also features a new splash screen image, a homepage tab to let you return to the homepage while a file is open, better node search when a space is used in the node name or search query, plus several other quality-of-life improvements and bug fixes.
Is there any plan to allow the distribution of private packages via the package manager?
This could be very handy for the distribution of packages inside businesses.
Cheers.
Not that I have heard, and I would be quite disappointed if it were added. One of the core philosophies of Dynamo is community, and package manager is a big part of that. Soon as ‘packages that aren’t for everyone’ are added it becomes a LOT less valuable for us all.
Introducing the option to distribute internal packages does not imply neglecting the community or becoming less open source. GitHub did not see a decrease in the number of open repositories or become less community-driven when it introduced private and internal repositories. Similarly, Grasshopper maintained its community focus when it added the capability to use the package manager for internal distribution. The primary goal of the package manager should be to facilitate the smooth distribution of packages.
Let’s say a company develops an internal library to streamline fabrication processes.
This library needs to be used by internal issuers, and every node is tailored to their internal process, bringing very low value to the community. Why should this package be public? On the other hand, the company can’t leverage the package manager systems to distribute the package internally.
After a couple of projects and iterations, the company will start to see value in abstracting some of the functions into a library that could benefit the community, so they open part of the library to everyone.
Returning to the previous point, the package manager should support both scenarios. If this is possible, the internal distribution, I will be happy to understand how, .
Why should a community resource foot the bill for distribution a tool that others cannot use? Doubly so when your internal team can already distribute and manage the package internally by way of configuring your end user’s environment by using GPL or other method to copy packages to end user’s systems on log-in thereby ensuring everyone can use the graphs the company develops?
For internal only packages you can write a means of authentication into your zero touch node to prevent external users from utilizing them.
I don’t see where adding the possibility for the package manager to install private packages will disadvantage the community, but I respect the decision.
Regarding internal distribution, yes, there are different possibilities, all with side notes.
The one you described will require more investment and time to deploy than distributing the package by email . This will clearly depend on the company’s dimension, IT relations, etc.
Asking internal users to install it manually is the most significant request possible .
Pointing to a shared directory is another possible solution with clear implications, a more manual process, user issues, and IT involvement.
Sometimes, the best option is to release an executable that limits user interaction. This is why I was asking if the package manager could take that owner.
But I got your point!
Thanks for the info and chat.
Why not just use an xcopy/login routine so the user doesn’t even have to think of it? Most packages are quite light, especially if built as zero touch. Nearly any IT manager out there could solve this with some basic policy work or a deployment app like PDQ/Intune in the market I suspect, or via a batch script (if an IT manager is good enough to say ‘no batch scripts’, they have no excuse not to know how to manage automated file/policy deployments).
Generally you could silently copy/update a package fairly easily in this manner, without the user even needing to install the package themselves, and if you did it to the default package folders, no need to deal with network path issues you mentioned also, and you have the benefit of controlling which Revit versions you support, and with which package variant if that is a requirement.
I second Jacob’s feelings that Dynamo if anything is one part of the Revit platform that is very intentionally open, and the value we’ve seen from this versus us all locking up our templates, families etc. in Revit as an industry has been powerful.
Hey @GavinCrump
Yeah, as I said, it always ends up to IT relations and internal policies and governance for distribution, so depending on that, it could be that the faster way is to create an executable that the user can download and install
I understand Jacob and your feelings, even though I believe sharing is more principle-driven by being a community than a ‘technical limitation.’
I will add that if your package is a ZeroTouch version, you could add a Wix installer to the Visual studio project to automatically create a installer for your package to then be utilised by your IT team as a distribution mechanism to install on all users machines via any standard IT solution(eg Intunes, etc).
Other option is to look at a tool John Pierson created for package installing, if it does not do what you want. You could look into this and develop your own version.
Sadly I have some enough historic knowledge to know that if private packages were possible things like Dynamo for Civil 3D wouldn’t have progressed anywhere near as fast as it has. As soon as there is a ‘private’ distribution mechanism the biggest AEC companies come in and scope up all of the talent in the thought that they’d have an edge on the competition, but thereby delay everyone’s common benefit.
@sonomirco We’ve heard similar interests from other community members. We understand the value of having internal package managers for some organizations, as it allows them to create more tailored packages for their users, meet security protocols, and mitigate the risks associated with third-party packages.
At the same time, as @jacob.small rightly pointed out, Dynamo community has historically relied on public packages driven by community contributions, which help Dynamo and this community grow faster as a group.
We acknowledge the need for internal package managers now that Dynamo has become a common tool in the toolkit for many organizations. However, we also want to carefully evaluate the new potential benefits versus the impact on the existing workflows.
So, to answer your question, we are very open to exploring the option of an internal package manager for Dynamo after we complete the new package management workflows that is currently on our roadmap.
We’d love to hear what more you’d like to do.
.
. This will clearly depend on the company’s dimension, IT relations, etc.
Lots of performance work, among many other things, underway right now.