Removal for Rhino8 flag in compas 2.9.0 too soon

[kangoananya]

Hi, we have been using COMPAS with the MAS ETH DFAB students in Rhino 8 but with the (now) legacy python -m compas_rhino.install. Our workflow was more or less same as Rhino7 - using the IronPython ScriptEditor in Grasshopper (we do not use the GH components). This works quite well (maybe only in our narrow world-view), as we could have conda environments for students where they can have multiple dependencies, and then choose to work in or outside Rhino.

Now, assuming Python3 component is the future for Rhino8 and COMPAS - the only way to replicate the workflow would be to have parallel conda and Rhino venvs to do this; which might be fine, but in my experience the Python3 component is semi-stable at best; so it feels a bit unnecessary to remove support for Python2.7 already. For now, we could stay in the past by using either compas 2.8.1 or Rhino7; but would be cool to understand how these workflows are envisioned in the long-run.

I have discussed this with @gonzalocasas briefly and he suggested with @chenkasirer @tomvanmele we could discuss this here. What do you guys think?

[chenkasirer]

Hi Ananya,

I'm really sorry we pulled the rug from under your feet.

The reason we decided to deprecate the -v8.0 installation option is that our trusty symlink installation (using compas_rhino.install) is not compatible with the new #r system (that uses pip) that McNeel introduced and can potentially conflict with it in a nasty way.
This decision was made following a lengthy (public) discussion here: #1351.

To use a conda environment from within Rhino, you could add your environment's site-packages to python's search path. This is more robust than adding compas symlinks to one of Rhino's default search paths (which is what we used to do) as it can be added per interpreter and does not modify Rhino's filesystem.

A neat way to do it over the GUI is explained here: https://developer.rhino3d.com/guides/scripting/editor-configs/

1. Open the ScriptEditor
2. Under Tools -> Options -> IronPython2
3. Add a new Module Search Path pointing to the site-packages of your conda environment

Restart Rhino and then you should be able to import stuff that's installed in that environment from both the script editor and GH IronPython script components:

Note that the environment surely contains packages that are not compatible with python2 and you will get an error when trying to import those.

Chen

[tomvanmele]

although i understand that these changes might create some temporary frustration, i do want to be clear about the future of these workflows (since you ask): we will drop support for IronPython completely in future versions of COMPAS.

maintaining support for IronPython has been extremely painful because the entire Python ecosystem has moved on from Python 2 many years ago. the only reason we went through all this trouble is because there was no other way to work in Rhino.

this need for extreme backward compatibility has put serious constraints on the development of COMPAS, and now that we can finally remove these constraints, we will move forward asap and not look back.

that said, we will obviously not abandon users who for whatever reason depend on older versions of COMPAS. we will help where we can to make legacy use still possible, at least for some time, and we will not drop support for (Iron)Python 2 immediately and abruptly.

i hope the suggestion of @chenkasirer already addresses your concerns at least to some extent. however, if possible, i would recommend to consider making the transition. the new ScriptEditor and the environment and requirement management have come a long way and are not as unstable anymore as a while ago. if you think it is useful, i am happy to share my own experiences and best practices.

anyway, i don't want to rub salt in the wound, but i figured it is better to be clear about the situation...

[kangoananya]

Hi Chen, Tom,

Thank you so much for your response. I understand python3 is the way forward for COMPAS and McNeel and I would be happy getting rid of IronPython; it just felt a bit soon, given my experience with the python3 component.

Regardless, I have been testing this workaround, with varying levels of success. Maybe, I mention first that doesn't work for packagaes installed in editable mode, since those are not present in site-packages. But leaving out that use case, I could only get it to work for some of my conda enviroments

In this one, which worked well with the "legacy" method, it seems to run into this issue here. However, with some other enviroments I have had success, ofcourse excluding the packages installed as editable.

But then, going back to the idea of embracing the change and moving to the #r method as McNeel probably wants us to; apart from the stability issues I already complained about (although I agree this has gotten better), this also has questionable success with combinations of packages. For example, compas + compas_fab is okay; compas + compas_timber is okay, but compas_timber + compas_rrc is not okay. Same for compas + opencv.

I might be doing something wrong, so looking forward to hearing your experience and best-practices and perhaps other workarounds. In the end, I understand we could still stick to older versions, so it is not a problem that has no solutions; it is more me questioning our workflows and the dependency on McNeel.

[tomvanmele]

if you leave a list of packages here that you want to be able to use (in addition to compas_timber, compas_rrc, opencv-python), i will experiment a bit and report back asap...

[kangoananya]

Thanks, Tom!

these are the combinations I can think of workflows with; perhaps we can add compas_fab to the list since it is a dependency of compas_rrc anyway and I noticed the same issue there in combination with compas_timber.

for now, what kind of works, is to separate the packages across components with different Rhino venvs and just share the data in between, but then it starts to get a bit ugly..

[tomvanmele]

i can install and import this combo without any problems. is there any code snippet i should try to test if it really works?

[kangoananya]

I was having the issue at the install itself, but now I can't seem to replicate the errors from earlier.

Perhaps, it was something transient.... Apart from the fact that I tested it in the Rhino ScriptEditor before trying it in the GHPyhton one, I doubt anything else changed; but now I can successfully import the packages together. In this case, we can perhaps try to go with this workflow and test it further; the Rhino venvs are a bit ugly but I guess that's the way unless we get rid of the dependency there. Thank you!