[Bug]: ironpython 3.4 fails to load in pyrevit 5 from WIP installers

[jj-github-jj]

✈ Pre-Flight checks

• I don't have SentinelOne antivirus installed (see above for the solution)
• I have searched in the issues (open and closed) but couldn't find a similar issue
• I have searched in the pyRevit Forum for similar issues
• I already followed the installation troubleshooting guide thoroughly
• I am using the latest pyRevit Version

🐞 Describe the bug

The system error: could not load type 'IronPythonruntime.list from assembly 'pyrevitlabs.Ironpython Version = 3.4.1.0
shows up when I changed the core settingst ot use ironpython 3.4
Also because of the above error, pyrevit doesnt show up on Revit 2023 as well and I had to re-install pyrevit to undo this core settings change to 3.4

⌨ Error/Debug Message

♻️ To Reproduce

Install pyrevit 5 from wip installers and change core setting to IronPython 3.4 and restart Revit 2023
You will see the error

⏲️ Expected behavior

no fail to load

🖥️ Hardware and Software Setup (please complete the following information)

==> Registered Clones (full git repos)
==> Registered Clones (deployed from archive/image)
master | Branch: "master" | Version: "5.0.0.24299+1037-wip" | Path: "C:\Users\user\AppData\Roaming\pyRevit-Master"
==> Attachments
master | Product: "24.1.1" | Engine: IPY340PR (340) | Path: "C:\Users\user\AppData\Roaming\pyRevit-Master"
master | Product: "23.1.3" | Engine: IPY340PR (340) | Path: "C:\Users\user\AppData\Roaming\pyRevit-Master"
master | Product: "2021.1.9" | Engine: IPY340PR (340) | Path: "C:\Users\user\AppData\Roaming\pyRevit-Master"
==> Installed Extensions
==> Default Extension Search Path
C:\Users\user\AppData\Roaming\pyRevit\Extensions
==> Extension Search Paths
==> Extension Sources - Default
https://github.com/pyrevitlabs/pyRevit/raw/master/extensions/extensions.json
==> Extension Sources - Additional
==> Installed Revits
24.1.1 | Version: 24.1.10.25 | Build: 20230830_0315(x64) | Language: 1033 | Path: "C:\Program Files\Autodesk\Revit 2024\"
23.1.3 | Version: 23.1.30.97 | Build: 20230828_1515(x64) | Language: 1033 | Path: "C:\Program Files\Autodesk\Revit 2023\"
2021.1.9 | Version: 21.1.90.15 | Build: 20230907_1515(x64) | Language: 1033 | Path: "C:\Program Files\Autodesk\Revit 2021\"
==> Running Revit Instances
PID: 11736 | 23.1.3 | Version: 23.1.30.97 | Build: 20230828_1515(x64) | Language: 0 | Path: "C:\Program Files\Autodesk\Revit 2023"
==> User Environment
Microsoft Windows 10 [Version 10.0.19045]
Executing User: ***
Active User: *** 
Admin Access: No
%APPDATA%: "C:\Users\user\AppData\Roaming"
Latest Installed .Net Framework: 8.0.5
No .Net Target Packs are installed.
Installed .Net-Core Target Packs: v8.0.300
pyRevit CLI v5.0.0.24299+1037-wip.8caf21fc8ed934cf3feb7be27704d326639c6607

Additional context

No response

[sanzoghenzo]

Thanks for the report.
FYI, you dont need to reinstall pyrevit to make it work again, just do pyrevit attach master default --installed in a command prompt as instructed in the troubleshooting guide.

[sanzoghenzo]

I can reproduce this on my machine, that has the pyrevit Dev tools extension enabled.

changing the end of pyrevit\loader\sessionmgr.py to the following shows the error but continues to load pyRevit:

    try:
        runtime.types.ScriptExecutor.ExecuteScript(
            script_data,
            script_runtime_cfg
        )
    except Exception as e:
        mlogger.error(
            'Error executing extension startup script: %s | %s', script_path, e
        )

But then no python script will run, outputting the same error as the OP.

This is the full exception stack trace I got while debugging with visual studio:

System.TypeLoadException
  HResult=0x80131522
  Message=Could not load type 'IronPython.Runtime.List' from assembly 'pyRevitLabs.IronPython, Version=3.4.1.0, Culture=neutral, PublicKeyToken=7f709c5b713576e1'.
  Source=pyRevitLabs.PyRevit.Runtime.2023
  StackTrace:
   at PyRevitLabs.PyRevit.Runtime.IronPythonEngine.SetupArguments(ScriptRuntime& runtime) in dev\pyRevitLabs.PyRevit.Runtime\IronPythonEngine.cs:line 266
   at PyRevitLabs.PyRevit.Runtime.IronPythonEngine.Start(ScriptRuntime& runtime) in dev\pyRevitLabs.PyRevit.Runtime\IronPythonEngine.cs:line 100
   at PyRevitLabs.PyRevit.Runtime.ScriptExecutor.ExecuteManagedScript[T](ScriptRuntime& runtime) in dev\pyRevitLabs.PyRevit.Runtime\ScriptExecutor.cs:line 189
   at PyRevitLabs.PyRevit.Runtime.ScriptExecutor.ExecuteScriptNow(ScriptData scriptData, ScriptRuntimeConfigs scriptRuntimeCfg, ScriptExecutorConfigs scriptExecConfigs) in dev\pyRevitLabs.PyRevit.Runtime\ScriptExecutor.cs:line 87
   at PyRevitLabs.PyRevit.Runtime.ScriptExecutor.ExecuteScript(ScriptData scriptData, ScriptRuntimeConfigs scriptRuntimeCfg, ScriptExecutorConfigs scriptExecConfigs) in dev\pyRevitLabs.PyRevit.Runtime\ScriptExecutor.cs:line 71
   at PyRevitLabs.PyRevit.Runtime.ScriptCommand.Execute(ExternalCommandData commandData, String& message, ElementSet elements) in dev\pyRevitLabs.PyRevit.Runtime\ScriptCommands.cs:line 279
   at apiManagedExecuteCommand(AString* assemblyName, AString* className, AString* vendorDescription, MFCApp* pMFCApp, DBView* pDBView, AString* message, Set<ElementId\,std::less<ElementId>\,tnallc<ElementId> >* ids, Map<AString\,AString\,std::less<AString>\,tnallc<std::pair<AString const \,AString> > >* data, AString* exceptionName, AString* exceptionMessage)

The root cause is that IronPython3 renamed IronPython.Runtime.List to IronPython.Runtime.PythonList, but pyRevitLabs.Runtime is only compiled against IronPython2.

I believe that we should move the PyRevitLabs.Runtime.IronPythonEngine (or at least the parts that directly depends on ironpython) to its own assembly, compile it against the various engines and put it into the engines folder.

The question is: @jmcouffin @dosymep are we willing to do this? I personally would like to focus on CPython 3 support instead of trying to support a library that was already old when it was released 🤣

[jmcouffin]

The question is: @jmcouffin @dosymep are we willing to do this? I personally would like to focus on CPython 3 support instead of trying to support a library that was already old when it was released 🤣

Agreed on the "oldness" ;p

If I am not mistaken, wouldn't it imply a lot of issues/refactoring?

• Revit API classes access issues
• WPF support
• Code transition from IPY to CPY3

[sanzoghenzo]

The question is: @jmcouffin @dosymep are we willing to do this? I personally would like to focus on CPython 3 support instead of trying to support a library that was already old when it was released 🤣

Agreed on the "oldness" ;p

If I am not mistaken, wouldn't it imply a lot of issues/refactoring?

* Revit API classes access issues

* WPF support

* Code transition from IPY to CPY3

What I meant is that I would like to try to bring support to cpython 3 alongside ironpython 2.7 rather than trying to make ironpython 3.4 work as engine for pyrevit

[jmcouffin]

What I meant is that I would like to try to bring support to cpython 3 alongside ironpython 2.7 rather than trying to make ironpython 3.4 work as engine for pyrevit

gotcha

what would be your arguments pros/cons?

[sanzoghenzo]

What I meant is that I would like to try to bring support to cpython 3 alongside ironpython 2.7 rather than trying to make ironpython 3.4 work as engine for pyrevit

gotcha

what would be your arguments pros/cons?

Not sure I follow you...

I already proposed to drop the IronPython 3.4.0 engine, and use only one IronPython engine at a time, in my plan proposal;
this will solve the many attachments issues we currently face, and make development easier (only one IronPython library to handle at any given time).

CPython is something that I always wanted to make it work because of the endless possibilities given by the various python libraries out there (for which I proposed the "dependencies" section in the extension manifest and the usage of virtualenv/uv for managing them).
As you said there are things to fix, mainly the pyrevit.forms (revit API shouldnt be an issue, but I might be wrong). I started to investigate it a while ago but didn't manage to solve it...

[jmcouffin]

to drop the IronPython 3.4.0 engine, and use only one IronPython engine at a time, in my plan proposal

Makes sense.

CPython is something that I always wanted to make it work because of the endless possibilities given by the various python libraries out there (for which I proposed the "dependencies" section in the extension manifest and the usage of virtualenv/uv for managing them).
As you said there are things to fix, mainly the pyrevit.forms (revit API shouldnt be an issue, but I might be wrong). I started to investigate it a while ago but didn't manage to solve it...

I agree, but I am a bit worried about it, as you mentioned you would not be involved anymore in 2025, I wonder if anyone could take over the task _ and I am sure chatGPT is not there yet ;p