Christopher Rowley
Christopher Rowley
> In fact I do wonder if that issue isn't a Julia bug (since we've never seen it anywhere besides the PythonCall.jl instance). Maybe it's due to how Python multithreading...
Can you please provide some code to reproduce the error you're seeing? I can start PythonCall just fine on Windows and Linux even with Numpy 2 installed.
Yep, we don't have anything like CondaPkg's various modes. Also CondaPkg has a notion of whether the environment it is installing into is shared or not (based on the mode...
No, it finds all these files and merges them together.
Yep unfortunately Julia currently uses OpenSSL 3.0 (this is apparently intentional) so for compatibility reasons we restrict the version of OpenSSL installed by CondaPkg. You can override this by setting...
``` CondaPkg Found dependencies: /home/akako/Documents/github/dotFiles/homedir/.julia/dev/UnROOT/CondaPkg.toml CondaPkg Found dependencies: /home/akako/.julia/packages/PythonCall/Nr75f/CondaPkg.toml ``` These two lines tell you where the dependencies come from. It's most likely your dev version of UnROOT.
You can now set `JULIA_CONDAPKG_OPENSSL_VERSION=ignore` if you'd like to turn off this behaviour. See the README for more info.
Yep I've seen what I think is the same thing before. AFAIU it's not really supported to call into Julia from a thread that wasn't launched by Julia (e.g. one...
Cool, I didn't know it was non-experimental now. It would certainly make PythonCall simpler if it could assume there was no GIL. However since the GIL gets re-enabled if you...
To answer my own question, yes there are some meta-packages to specify which flavour of python to use. https://anaconda.org/conda-forge/python-freethreading So someone can already just add python-freethreading to their CondaPkg.toml to...