Is it possible to have multiple versions of Node Packages?

python
orchid
dynamo

#1

Is it possible to have multiple versions of any Custom Node Package in Dynamo? I created a lot of Scripts with Packages that work quite well. If I update the packages now, I also need to update a lot of my Scripts and test them again. This I want to avoid.
My idea would be to somehow rename the Package to have e.g. “Clockwork V1” and then the latest one as “Clockwork V2” and in some month probably “Clockwork V3” when I update again.
Does anyone know how to do that?

Thanks a lot in advance


#2

It is doable to do this, you even dont need to name them in any special way, however, you need to have a folder for packages seperated into the different dynamo versions. By default will dynamo be installed this way, so it should be safe to have different versions of packages.

As you can see, I have packages that are independent of versions installed in a “common” folder, and the version specific in the version specific folders. I have not unfolded the “Dynamo Core” packages, but they are nearly the same as the packages in the “Dynamo Revit” folder, click at the image to see it in full size!
…the “OrchidSandbox” is my “playground” where I build new nodes that are not published yet :wink:


#3

Hello erfajo,

thanks for your reply. I know its possible to have different versions of Custom Packages in different Dynamo Versions.
I am looking for a way to have multiple Custom package Versions in the same Dynamo Version like shown in the Picture below.
I want to have your new Package but also the old one as it is. Is there a way to rename on of these two so that Dynamo thinks these packages are not the same? I tried with renaming the folder, renaming the package.json but without success.


Thanks


#4

I would not recommend this - you’re more likely to break Dynamo in unexpected ways.

It is possible to document all packages in a given graph (monocle view extension), and you can then build a database from that info to limit the amount of testing required. Or better yet build a graph or two that tests every nodes in a given package, and produces outputs which should result in a verifiable outcome, IE:

ResultList == (1…4) ? “UpgradeAway!” : “Test This Index” ;


#5

I would choose to make two different network paths to my packages.
Save the updates after testing to the new location leaving the working old nodes where they are now.
When you are done updating switch to the new location. Thing is that this will probably happen again in the future (i hope).


#6

I have to backup @JacobSmall on this one, It is not recommendable to have two versions of the same package to be used in the same Dynamo application.

Nodes are stored with an id for every node. In the case with CN nodes are it most likely they are the same. Otherwise is it almost impossible to “upgrade” between 1.3.x to 2.0.x versions. In that case, would you need to rebuild all graphs! For ZT nodes is it different, if you chose to code it as so. Most likely will noone have these split, I dont. This means that you end up in the same confict, having two nodes with the same name/id to do the same job. It is highly unpredictable which will be used.

However, you do also point on two different version of Orchid, which are in the same range --> 201 and 202… they are the same, if not, then please report this as an issue at my GitHub so this can be fixed, it is absolutely my fault if this gives you errors :slight_smile:


#7

Alright Thanks Guys, then I will do it that way that I will have them seperately and replace them after the upgrade :slight_smile:


#8

Hello @erfajo

I updated now the package and i have troubles with some nodes. Following the example with Directory.ContentsAll that gives me an error that I do not understand.
aaa
The Folder where I always put the nodes is under “AppData\Roaming\Dynamo\Dynamo Revit\2.0\packages”.
Could you please help me whats the problem here?
Regards


#9

I have to ask @Michael_Kirschner2 for this one…
Is there any changes between nuget version 2.0.2.6986 and 2.0.1.5055 concerning the DynamoCore assembly? and what if I update to 2.1.0.7465, will this then go even worse?
I have not got any other user errors with this error so it is a bit strange!?


#10

Hi @erfajo - 1. what version of Dynamo core do you reference in your dlls? I’m not sure why the dynamo core dlls are being searched for in this core location - 2. do you do anything special to search there for it?

@gerhard.schindler what version of dynamo are you using?

in general as a package author I would target the earliest major version possible to get compatibility with other dynamo versions that users may have installed. While we do try to avoid binary compatibility breaks to meet semantic versioning https://semver.org/ - it’s not always possible, having said this, I don’t think 2.0.2 and 2.0.1 have many changes - here is the diff.


#11

I learn more in two minute posts like this involving people like @erfajo and @Michael_Kirschner2 than I do in nearly every other aspect of my day. Thanks to both of you for the insight :slight_smile:


#12

@Michael_Kirschner2, I use the nuget 2.0.2.6986 packages…
But I dont use the core assembly in that node. However, the core assembly is used in the overall assembly as such. In that node do I only use the .net system assembly. Thats why I find it strange that the core assembly is failing!?

using System;
using System.Collections;
using System.Collections.Generic;
using System.IO;

I agree that using the earliest major release is the most secure, however, 2.0.1 and 2.0.2 should be quite the same. This is why I have not changed to the 2.1.x series.

@gerhard.schindler I have an idea… it is possible that the error is another. I would like to test this, for doing this I need your dynamo file without is has being re-saved in a new version.

If I am right, then I think I can solve it, and in that case will I write my observations on the dynamoDS github

@JacobSmall, You are welcome, but I have to admit that it can become kind of geeky from time to time for some of the curly questions I ask @Michael_Kirschner2 :wink:


#13

First of all thanks for your help and investigation in that specific case :slight_smile: U guys are just amazing.

@Michael_Kirschner2 I am using The Following Dynamo Core and Dynamo Revit Version:
2019-02-01%2007_29_23-Einstellungen1
I know the versions are not up to date, but we have this Version in a Pre-defined Installation Package and as long as there are not really crucial changes, we dont want to update to newer versions to make sure everything is still working. Is this fear useless and we should update? I just want to be sure that with an update our Scripts still work.

@erfajo I uploaded the easiest script with your Directory.ContentsAll that I found. I also included the node Formula.SetValue because here I get the same error.
TestScript.dyn (9.0 KB)

Thanks already :slight_smile:


#14

I found the problem, but I can’t solve it so I have to report this issue at DynamoDS Github…

(@Michael_Kirschner2) It seems that migration doesn’t work internally in the 2.0.x version. It work fine between versions. I tried to find old 1.3.x graphs and they migrated perfectly into 2.0.2. Graphs from 2.0.x, where nodes need migration, is failing!

The two nodes left are both named "List.Clean", but that node changed its "namespace" at some point. The two nodes right are the same, but the node name changed from "Directory.ContentsAll" to "Directory.Contents". If I tried the same with a 1.3.x graph they migrated perfectly!

TestGraph.dyn (8.6 KB)
Capture

postedit
the issue at Github can be followed here

the issue is also connected to this


How to properly use Migrations.XML with a ZeroTouch nodes package?
#15

Try to see this proof of concept for solving the issue