ScriptEditor Grasshopper components with PyPi dependencies

[Petras_Vestartas]

@eirannejad

What would be the best way to distribute grasshopper components with script editor?

The problem is about pypi installation when # r: keyword is specified.
From the video you can see that components install or check the pypi package multiple times. I imagine that installation is needed only once. This also happens if you drag and drop a component to grasshopper canvas.

How to avoid these multiple checks and have installation only once?

Second 25, the two components do the same check. The PyPi dependencies were even installed before loading rhino.

[eirannejad (Ehsan Iran-Nejad)]

@Petras_Vestartas Have you seen this video by any chance? This is the direction we are going with in Rhino 8 to publish rhino and grashopper plugins (from scripts and script components) from then new ScriptEditor:

Publishing Your Scripts as Rhino/GH Plugins

I do not see how pip is installing packages multiple times. Would you mind clarifying if you are publishing your scripts using the method in the video above?

Any way you can share a test published gha that replicates the problem?

[Petras_Vestartas]

The issue, is that for grasshopper section you are showing a C# component, not python.

How you would create these components using the following folder structure?

compas_wood/src/rhino/gh/cpy at main · petrasvestartas/compas_wood

We are using componentizer to create user objects: GitHub - compas-dev/compas-actions.ghpython_components: Trying to make Grasshopper development version-control friendlier since 1337. else it is impossible to publish such Rhino code to Github and have clear version control.

[eirannejad (Ehsan Iran-Nejad)]

@Petras_Vestartas

It is still not clear to me how to replicate this. Do you have a set of user objects that have this problem?!

From the video you can see that components install or check the pypi package multiple times.

Thanks for pointing me to the project. From what I can gather, this is a good way to export user objects (They are technically NOT plugins). It seem like they are automatically generating a UserObject archive using the guid of the ‘new’ script component, and setting the script inside this component.

So all the user objects are creating the new script components that would handle package installs.

The componentizer developers might have to update their code depending on the changes to the script component archive format since is it not guranteed api.

[Petras_Vestartas]

This is the example:

petrasvestartas/compas_wood/blob/main/src/rhino/gh/examples/10_vidy_chapel.gh

It does not matter if it is a user object or just python code in script editor that has # r.

The workaround to this problem is to have a component that only has #r keyword. So it installs once. And then the rest of the components would not have #r keyword.

But it does not seem like a good approach for distributing plugins?
When you install a plugin via package manager, this should be it. But this is only valid for .NET not for Python.

[eirannejad (Ehsan Iran-Nejad)]

Package: compas-wood - Installed Module compas_wood
Package: wood-nano - Installed Module wood_nano

This really should not matter for pip as it works with both:

$ pip install wood_nano
$ pip install wood-nano

But always reports package name:

$ pip list
Package    Version
---------- -------
wood-nano                 0.1.1

After installing compas-wood package I can see that the metadata reports the package name as compas_wood which does not match the name of package published to PyPI:

Metadata-Version: 2.1
Name: compas_wood
Version: 2.1.0
....

This means pip reports the module as compas_wood

Info 05/08/2024 18:00:33 [RhinoCode] ========> Installed packages: "Python 3.9.10 (mcneel.pythonnet.python)"
Info 05/08/2024 18:00:33 [RhinoCode] => Environ: "default"
...
Info 05/08/2024 18:00:33 [RhinoCode] compas_wood==2.1.0
...
Info 05/08/2024 18:00:33 [RhinoCode] wood-nano==0.1.1
...

It is a discrepancy but is it ok. My code that checks for whether a package is installed or not pays too much attention to _ vs - and I will get that fixed:

RH-81913 CPython env checker is paying too much attention to hyphen vs underscore

Problem

You have specified the wood-nano package as wood_nano which the package to get installed correctly, BUT reports as wood-nano and causes this bug to appear.

After fixing the package names and running the definition things seem to be fine:

Thanks for reporting this and sharing the code

[Petras_Vestartas]

Wow! Thank you!