Template for creating a package from many nodes?

[truevis]

I would like to make a more formal package for all the little nodes I have made. Up to now I have just been publishing nodes one at a time with category ‘truevis’.

I suppose it would be best to start a GitHub repository for posterity. I have been publishing Gists of Python functions, et cetera, so I remember what I did and to share.

A method of separating by Revit versions would be good, too. It seems other package publishers struggle with that. I made a folder structure for a client for its apps:

Would that work for a package?

Any advice to start off on the right foot?

[chuongmep]

I saw this happen with many developer when publish a python package to make sure can work with all version like : GitHub - andydandy74/ClockworkForDynamo: A collection of 450+ custom nodes for the Dynamo visual programming environment.
With me, I’m still recommend let move to Zero Touch Node to do that, and make sure cilent don’t have any issue when they use package also easier for maintain your package with new version.
My opinion, Python pacakge is hard to maintain and keep upgrade new node for now between ironpython and cpython3 .

[truevis]

@chuongmep

Python package is hard to maintain and keep upgrade new node for now between ironpython and cpython3

Can that be mitigated by starting with Revit 2022.1 and only using CPython3?

[chuongmep]

It can be good if you can cover case API updated and removed in Revit API, Especially with APIs directly related to the unit, parameters, I am not sure they will work perfectly with all but if you are more familiar with Python, you must probably pursue them, good luck

[truevis]

I see GitHub - albandechasteigner/GeniusLociForDynamo: Genius Loci is a package of 350+ custom nodes for Dynamo in Revit. but it does not have separate Revit version versions. Is that workable because it only uses nodes with Python and no DLLs?

[chuongmep]

It is feasible if you can check the exceptions to the difference in API update between versions in the same node. Python is a dynamic language, so you need to work and check a lot if you are doing so, I’m not sure how long you will take if the maintenance for more than 300+ nodes. Below is an example I want for example, I’m also a big fan with Python for a long time but I also do not recommend it to you for develop a package in Dynamo Revit .

Autodesk.Revit.DB.UnitType.UT_Length

Hi! Just a noob question I’m in trouble with those lines of code from a script written by learndynamo.com getDocUnits = doc.GetUnits() getDisplayUnits = getDocUnits.GetFormatOptions(Autodesk.Revit.DB.UnitType.UT_Length).DisplayUnits Does anybody know how to solve this? I’m working on Revit 2023. Thanks!

[Alban_de_Chasteigner]

Hi,

Indeed there are numerous examples in my Github showing how to manage multiple versions of Revit and changes in the API.
For me this is not easier to handle in C#. I’m maintaining addins from Revit 2019 to Revit 2024 and it’s a real pain.

albandechasteigner/GeniusLociForDynamo/blob/26e52d15935ab16ff613058c5e9f3f310d81bdd0/Nodes/Set SystemType Properties.dyf#L23-L33

[truevis]

@Alban_de_Chasteigner

Indeed there are numerous examples in my Github showing how to manage multiple versions of Revit and changes in the API.
For me this is not easier to handle in C#. I’m maintaining addins from Revit 2019 to Revit 2024 and it’s a real pain.

I see you are doing it in the code to make each node compatible with many version of Revit.

if version < 2021:
   UIunit = Document.GetUnits(doc).GetFormatOptions(UnitType.UT_Piping_Temperature).DisplayUnits
else:
   UIunit = Document.GetUnits(doc).GetFormatOptions(SpecTypeId.PipingTemperature).GetUnitTypeId()

Do you find that works better or is easier than having separate files for versions of Revit?

[Marcel_Rijsmus]

What do you guys think of the @john_pierson solution?
Just curious…

[john_pierson]

My solution is all zero touch (c#) and it is built per Revit version. This then loads on the fly with a view extension.

This is extremely different than python nodes.

I would follow what @Alban_de_Chasteigner mentioned as it seems to work well for him.

Also, a GitHub is way more than “for posterity”…

Version control is extremely important and often overlooked. It also helps build the community because it’s open source and teaches coding principles upfront.

I find it a bit disappointing that @truevis thinks it’s for “posterity”, but ah well.

[john_pierson]

@truevis

Do you find that works better or is easier than having separate files for versions of Revit?

This is more stable in the long run. Separate files means several different versions of your package. Which isn’t great.

Also, worth a read: Keeping Your Sanity as a Dynamo Package Creator

[truevis]

@john_pierson

Separate files means several different versions of your package. Which isn’t great.

Thus if one is publishing nodes that use Python, one has to test the same node in all targeted Revit versions. Also onerous. Looks like there is not one perfect answer.

Good stuff about Semantic Versioning. Imagine if we had such canonical direction for publishing Packages!

GitHub for posterity because I don’t expect anyone to contribute, and I get an organized copy of my work off of my personal computer.

[truevis]

Found a README template on GitHub. This can be a start, then one decides whether to add Revit version folders or to try to make nodes that work in multiple Revit versions.

[ruben.romero]

Keep in Python so we can see what doesn’t work more easier and create other script versions from that reference. I don’t use package nodes just see how is done the script which is great to learn