Question:
- Can I run a Dynamo function from the ribbon within Revit?
- How do you share your functions with other users, the obvious answer I have so fare is through a shared directory?
Hi Neil,
(1) You have to run your Dynamo definitions through Dynamo. We’ve talked about building functionality to allow people to “wrap up” a Dynamo definition, but that would be a ways off.
(2) A shared directory is good for exchanging files, but we don’t yet support it. (Internal issue MAGN-1030) For now, custom node files have to be stored at: C:\Users<em>your_name\AppData\Roaming\Dynamo\0.7\definitions.
See this post for more on where files must be stored. Alternatively, if you are not trying to hide your definitions, you can share them with the broader Dynamo community through the Package Manager… under the “Packages” menu at the top, and also at DynamoPackages.com.
Hey Colin
Are we still limited to the local appdata folder for custom nodes?
To my understanding, this limitation means that teams sharing custom nodes have the following choices:
- Copy *.dyf files into their own appdata folder and re-copy anytime anyone changes the custom nodes(s)
- OR Share them through the package manager, which is not an option for proprietary work
Thanks!
B
Brian-
What we have done is set up a master “definitions” folder that will copy over to each user’s computer nightly - making it IT’s problem to resolve.
That said, I do think this is one area that the Dynamo development team should look into addressing sooner rather than later. I doubt that there are too many “power users” in each office/firm that are actually creating Dynamo definitions. More than likely there is one or two people that are building tools for everyone else to use, thus those one or two people need some easy way to ensure that the rest of the users they support are working with the same set of tools at all times. It’s not just internally developed custom nodes that need to be matching, but also the versions of downloaded packages that each user has on their machines that need to be matching. I’d like to see some sort of .ini file that could point Dynamo where to copy packages and definitions from each time it is opened. Might take a few extra seconds to open, but it would be ensure consistency. The Firm’s Power Users could keep their versions of Dynamo operating with the current functionality to allow testing of new packages and developing of new nodes, but the rest of the Firm user base would always only have access to the “approved lastest” list of packages and definitions.
I would be very hesitant to suggest using packages for something that is internally developed specifically for your company. Not so much from an IP standpoint as from a usability standpoint. Much of what you develop is likely looking for parameter names, families, etc that is unique to your office. Using the Package manager as your internal distribution tool could do more harm than good to the community as a whole as the Package Manager may get bogged down with a lot of “crap” that is not beneficial to the community as a whole.
I agree with Ben. Sharing your internal nodes and definitions via Package Manager is creating a lot of “noise”, and can lead to overall community discontent. I personally hate when people upload stuff that cannot be easily adopted elsewhere. Speaking of sharing nodes, and definitions internally, I haven’t “really” thought about it, because so far I am the only “power user” that uses Dynamo on active projects. Sharing, as well as training is something that we haven’t addressed yet, and having a “private” Package Manager would be awesome. For now I mostly upload nodes to archi-lab package for stuff that I am ready to share with external users and not only internally, but for things that I am not willing to let go into the wild I just never wrap them up into custom nodes. That way I can share then as part of *.dy file. I am glad that we are having this conversation now, because I will be in need of a viable solution rather sooner than later.
Ben and Conrad
Thank you for the input. I agree - I would only release a package if we had developed a body of work over time with more general applicability. For now we have a small set of tools that are specific not only to internal projects but also, as Ben has suggested, to internal content and naming conventions.
This issue of custom nodes came up within a few days of implementing Dynamo on a live project so it’s struck me as fairly significant. Version control of Dynamo and external packages* is easy enough to handle through IT, but for internal custom nodes we will likely need to make sure that team members are communicating updates with one another.
I think it’s less about having an internal package manager and more about being able to point the custom node directory to a server location. Internal custom nodes will likely vary from project to project and have no need to be coordinated firm-wide unless they’re harvested after a project based on notable general applicability. This is not unlike custom content creation in the Revit environment. Hey, maybe Unifi could get into the custom node management game…
This whole issue is really not so different from managing user objects on the Grasshopper side so it’s nothing new. We make them custom per project, share and manually sync among a limited user set when in-progress, harvest the useful ones post-mortem, and redeploy globally as a cleaned-up user object collection or Grasshopper library. So it would follow that, when a set of custom nodes mature into a useful toolset, they can be imported as a library into Dynamo and, if shareable, published as a public package.
*These can be freely downloaded/managed by the user with no IT restrictions but we can advise firm-wide on which packages and versions are approved for use on live, collaborative projects.
Brian, Ben, and Konrad, thanks for the insight! Your explanations are really helpful about what you are looking for and why.
@Brian – It’s also now officially part of the famed MAGN-1030.
I agree that an internal Package Manager would be a great, great thing. It may not be in wide demand right now, but if you were to develop this early it would prevent the kind of package cluttering of the public domain from happening at a large scale. We will definitely use it here at NBBJ.
Marc
An internal Package Manager would be awesome and would encourage the Dynamo developers to take a look at it. One of the great things about the current package manager is that there is no need to submit an office IT request and get custom nodes/plug-ins installed. Users can do it themselves quickly and efficiently.
Whether people decided to go down the (public) Package manger or local server route, is there a way to workout which custom node version you are using? I know that Dynamo will prompt you if a new version is available but what about all the published custom nodes? I can’t find anywhere where this is documented. Currently, I just go to the package manger almost daily to check. There must be a more efficient method. Grasshopper has the same problems and it drives me nuts.
Paul - regarding that last bit about new versions see this feature request and the response: https://github.com/DynamoDS/Dynamo/issues/484