Benedikt Reinartz
Benedikt Reinartz
I don't know what you mean. User assemblies are just loaded using `Assembly.Load`, which resolves the dependencies automatically and (to my knowledge) without an option to modify behaviour. We could...
How does that help?
Python.NET is already initialized at that point. ```python import clr # => Python.Runtime.dll is loaded from site-packages clr.AddReference("SomeDll") # => SomeDll has a reference to Python.Runtime.dll *and* has another instance...
The only thing we could do at that point would be to throw an exception, though. I don't think there is a way to fix the situation once the second...
It is not a bug per se, it is just unimplemented, see: https://github.com/pythonnet/clr-loader/blob/master/clr_loader/netfx.py#L26-L34 PRs are welcome, it's probably enough to add a new function to the `ClrLoader` .NET project that...
The problem doesn't happen with `r3:do(compile).` on a rebar shell, though.
Now that EEP-48 has landed, use these instead.
The patch also contains a test, if I'm not mistaken ...
It sure is. Frankly, I wasn't aware that this one here is the backports project, I'll file a bug for Python 3.3.
This is the upstream bug: http://bugs.python.org/issue24900