We are going to make improvements to the Workspace References extension over the next quarter, enabling you to not only see installed or missing package content and resolve it, but also understand what else your Dynamo graph requires to run on someone else’s machine.
This means local things such as Excel files, CSV files, images, DWG’s etc., and also local Dynamo nodes such as Custom Nodes (.DYF) and local ZeroTouch nodes.
But… we have a problem! We want to know if our three category names make sense Below we have a UX design mock-up of what we are thinking:
Could we see the path for loaded Packages as well?
For those of us that develop and distribute graphs for internal use, we often have additional packages loaded for testing. It would be nice to confirm that the packages in my graph are all coming from a public location and not my local testing folder.
That would actually be nice. Not necessarily a full description of references and paths, but a check to make sure you have all the supporting files before you run anything from Player.
Wondering if it can be integrated into Dynamo Player too ? This would be really cool to our Dynamo users. @a.halim
That would actually be nice. Not necessarily a full description of references and paths, but a check to make sure you have all the supporting files before you run anything from Player. @Nick_Boyts
Dynamo Player is currently being worked upon to improve (Starting with back-end refactoring) and will seek to improve this exact experience. It’s a little tricky as the Dynamo Player uses the Dynamo CLI (Command Line Interface) to execute Dynamo graphs - which is headless - so none of the UI features, Workspace References included, will show up.
@nate.peters and the Player team are looking closely at how to unify Workspace References and the GDiR ‘Pack and Go’ experience as we speak.
Would it be possible to have a warnings dialog box pop up that says something like “Not all necessary items are present. Please open the file in dynamo for more information.”
Not necessarly something I would want. Too scared it would mess up CLI style of running dyn scripts like in pyRevit. Popup are already a nightmare in Revit for any addin software developper, so let’s not bring that into Dynamo, please.
My 2 cents,
Good idea in general, I am not so sure about the naming:
Workspace References, it feels like Autocad . End of the day the workspace is a dynamo definition or a script. Nobody calls it a workspace. We share Dynamo Graphs, Dynamo Files, Dynamo Definitions, not workspaces. I’d rather go with something like Graph References
Packages, fine, same language as in the rest of the UI, External Packages,
Local Definitions, not sure about that one. It could be: A custom node or local zero touch nome, but also a local zero touch set of node therefore a package. Why not Local Packages, that makes it more inclusive imho
External files in this context does not make sense to me either, what can I do . They are external to the dynamo environnent, I get it, but they probably are local resources that are missing (or not). Extra files , they are not dynamo related and we do not qualify them as external as opposed to internal.
On the whole great suggestions - here’s a few comments:
Workspace References is the name of the overall extension that was released in previous versions of Dynamo. Understood that it feels a little AutoCAD-y, but it also thematically fits the notion of where you work inside of Dynamo. To rename to Graph References we would have to trade-off the existing cost of how users see, use, discuss and understand it today versus a renamed state.
The reason we have Packages vs. Local Definitions is that locally you don’t need to have created a package and can have floating DYF files. Any content on the Package Manager is by it’s very definition a Package. Either way we’re a not fully capturing the state of play in a single title - it’s either a local package or local loose DYF files and neither name matches fully. Bit of being between a rock and a hard place on both these names unfortunately.
External Files is a common pattern in software, speaking as you note to content external to Dynamo itself.
There is no issue with rebranding stuff usually @Autodesk _ me thinking out loud B360 Sorry I could not help myself and I do get the argument. It is a trade-off historically talking but would make it more comprehensive on the long run.
adding a package is modifying your core Dynamo workspace
Indeed. And it is a bit late to talk about the whole architecture of it. Packages are great as it allows you to add a lot of tools / blocks to your library of tools all at once. But the version management is a pain. Stuff like orkestra allow you to manage it somehow. But managing it for a whole remote team without a vpn->server access and with the ability to add whatever package whenever to its dynamo library has been a pain point from day one. We always find ways, and the workspace ref extension addresses some of it which is a step in the right direction, but the actual ways are painful to say the least. Right now I spend more time debugging dyn graphs due to package or dynamo/revit version hiccups than making actual graphs to improve workflows
≥ But the version management is a pain… Right now I spend more time debugging dyn graphs due to package or dynamo/revit version hiccups than making actual graphs to improve workflows
@Jean-Marc - We are aware of the issues and have made some tracks in helping on that front over the past year or so (Verbose error messages for the top 30 most common errors, extended documentation frameworks etc.) and have more planned. The Workspace References extension is indeed a step in the right direction, but only the first step of many
We are improving said extension and thinking more holistically about how to better deal with dependency and version conflicts in Dynamo.
Below we have a UX design mock-up of what we are thinking:
For example, local .DYF files, or ZeroTouch nodes that you have on your machine and loaded into the Dynamo space.
We can wrap that in as well.
. End of the day the workspace is a dynamo definition or a script. Nobody calls it a workspace. We share Dynamo Graphs, Dynamo Files, Dynamo Definitions, not workspaces. I’d rather go with something like Graph References
. They are external to the dynamo environnent, I get it, but they probably are local resources that are missing (or not). Extra files , they are not dynamo related and we do not qualify them as external as opposed to internal.
Sorry I could not help myself and I do get the argument. It is a trade-off historically talking but would make it more comprehensive on the long run.
