Make sure componentizer builds Rhino8-compatible components

[gonzalocasas]

I am checking this pull request too for different windows and mac versions. I am wondering if there is any problems with Rhino8 Grasshopper componentizer. For .NET development all the plugins needs to be currently and in the future Rhino8, Rhino9 WIP releases be rebuilt from .NET framework to .NET Core to make code execution faster. Is this somehow handled in the current workflow? But I do not know if this is valid for Python non compiled components.

Originally posted by @petrasvestartas in https://github.com/compas-dev/compas/issues/1384#issuecomment-2306857769

Indeed, componentizer will need to be updated. Componentizer already can generate cpython script components, but it needs to be able to generate ironpython script components (ie. the new script component, but selecting IronPython2). And the releases of compas and extensions will need to bundle both builds of legacy + new components and install accordingly. Components are shared across rhino versions, so this might be problematic.

[petrasvestartas]

I am wondering why compas components are not shared using Rhino package manager? Rhino made YAK exactly for this problem. It has version control related to both OS versions and Rhino versions, which is not only 6, 7, 8, 9 WIP, but also sometimes changes within monthly releases. What I mean, under rhinoscriptsyntax, RhinoCommon.dll and C++ backend changes within a version itself, if someones asks on McNeel forum to implement something.

I guess both workflows are possible just somehow this needs to be checked on multiple case studies. I was always using package manager, but I will look in detail about compas installation.

---

On another note, it would be nice to create "toolbarizer" for rhino plugins :) Since CPython is calling .NET for creating toolbar, there should be a way to automate this using Python without manually creating a plugin in rhino.

---

I will focus on the legacy compas components of rhino 7/8 to understand the problem better.

[gonzalocasas]

This might indeed be a call for change, I know that in EPFL, Andrea Settimi was using componentizer together with yak to produce properly distributable installs. We should try to do the same

[petrasvestartas]

In the past, how you were running ironpython to build grasshopper components of compas?

On completely new PC I do this:

(base) C:\brg\2_code\compas> conda create -n rhino8_scripts python=3.9.10
(base) C:\brg\2_code\compas>conda activate rhino8_scripts
(base) C:\brg\2_code\compas>pip install -r requirements-dev.txt
(rhino8_scripts) C:\brg\2_code\compas>invoke build-ghuser-components

The building process requires ironpython, which is not there. I could manually download ironpython and add to environmental variables, which makes the invoke method work, but I am sure this is not what you were doing before.

[chenkasirer]

In the past, how you were running ironpython to build grasshopper components of compas?

On completely new PC I do this:

(base) C:\brg\2_code\compas> conda create -n rhino8_scripts python=3.9.10
(base) C:\brg\2_code\compas>conda activate rhino8_scripts
(base) C:\brg\2_code\compas>pip install -r requirements-dev.txt
(rhino8_scripts) C:\brg\2_code\compas>invoke build-ghuser-components

The building process requires ironpython, which is not there. I could manually download ironpython and add to environmental variables, which makes the invoke method work, but I am sure this is not what you were doing before.

Indeed that's what I have been doing. invoke build-ghuser-components compiles user objects for IronPython and needs an IronPython interpreter available.

I did meet with Andrea to try and understand what needs to be done to make compas_timber distributed with YAK. Andrea built quite a cool Github Actions pipeline that does that.

Main challenges are: CPython By appending the # r: compas_timber to the top of the component modules, GH will install compas_timber using pip when first run. However, compas_ghpython currently doesn't work in CPython components. This has to be fixed before we can look at packaging it.

IronPython Here I'm not sure if the r notation is working, at least couldn't get it to work on my installation. YAK does not seem to have a mechanism for running arbitrary scripts so it cannot run python -m compas_rhino.install for us. Not sure what we can do here. Plus, as @gonzalocasas mentioned, the componentizer would have to be adapted to produce Rhino8 IronPython user objects. Currently it produces the Rhino7 ones, which, when opened in Rhino8, show with ad OLD label.

[petrasvestartas]

@chenkasirer

CPython I asked McNeel to implement installation of pip packages when you "click" install on the package manager, so both Grasshopper components, Rhino Toolbars and pip packages will be installed in the future same as .NET or C++ applications. Here is the opened issue: https://mcneel.myjetbrains.com/youtrack/issue/YAK-330

IronPython How many plugins are we talking about that depends still on IronPython? How much work would be needed to completely rewrite for CPython? I have a feeling IronPython was always a transition phase for McNeel and just looked at Python more seriously only recently. My personal preference would be to drop IronPython support.

Developer VS User I think compiling components for 7 and for 8 works. But what is confusing is the user experience. I would completely separate these two things: a) developer compiles Grasshopper components on its own as well as pip or conda packages and is responsible for distribution of them, b) user never goes through compas installation and use package manager. For ordinary non-coder even small command-line or bash scripts, i think, is not needed and really adds frustration. Currently you can add "Install" component with #r and in the future this will be handled by the package manager.