Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Python 3.9 julia Overhaul #2749

Open
wants to merge 29 commits into
base: feat/py39_rebase
Choose a base branch
from

Conversation

JacksonBurns
Copy link
Contributor

The Python 3.9 Upgrade is complete, but the new juliacall setup does not work. Current theory is that julia cannot 'see' the Python environment and/or its dependencies. Will address here.

@JacksonBurns
Copy link
Contributor Author

The pure-python tests fail on MacOS because between Python 3.7 and 3.9 the way multiprocessing works was changed (see https://stackoverflow.com/a/72830812) - we violate the requirements for using this new method (see https://docs.python.org/3/library/multiprocessing.html#the-spawn-and-forkserver-start-methods) so we may just need to set the method back to the old way.

@JacksonBurns
Copy link
Contributor Author

Using PythonCall with an existing conda environment: https://discourse.julialang.org/t/how-to-use-pythoncall-with-a-previous-conda-environment/87419

the PYTHONCALL suggestion is here: https://discourse.julialang.org/t/how-to-use-pythoncall-with-a-previous-conda-environment/87419/8

changing to current will hopefully prevent condapkg from making a new environment
@JacksonBurns
Copy link
Contributor Author

Setting JULIA_CONDAPKG_BACKEND to System caused RMS to install new conda packages during its build, since it could not 'see' the rmg_env conda environment. This resulted in the newly installed Python not being on the path, and then failing to find its encodings module during import (and thus killing the CI run).

Now attempting to set JULIA_CONDAPKG_BACKEND to Current, which should make RMS 'see' the rmg_env.

@JacksonBurns
Copy link
Contributor Author

Julia sees the correct environment (I think), so next is solving the error that Julia can't see the libraries. I think this may fix it: https://stackoverflow.com/a/77206459

@JacksonBurns
Copy link
Contributor Author

PYTHONPATH is likely set incorrectly, see: pythonnet/pythonnet#2147

@JacksonBurns
Copy link
Contributor Author

@JacksonBurns
Copy link
Contributor Author

Another person with the same issue; no solution - https://discourse.julialang.org/t/pycall-installation-on-macos-m1/87980

@JacksonBurns
Copy link
Contributor Author

More related: JuliaPy/PyCall.jl#410 (comment)

…se; and...

check that PYTHONHOME and PYTHONPATH are unset, both of which have a high likelihood of messing up the install process
@JacksonBurns
Copy link
Contributor Author

Next debugging step is to set JULIA_PYTHONCALL_EXE to the python executable rather than setting PYTHON: https://juliapy.github.io/PythonCall.jl/stable/pythoncall/#If-you-already-have-Python-and-required-Python-packages-installed

@JacksonBurns
Copy link
Contributor Author

ARM-mac can't see encodings, Ubuntu and Intel Mac can't see rmgpy...

@JacksonBurns
Copy link
Contributor Author

Seems that for Ubuntu the install works, but then during tests Python can't find it's libs - likely candidate is Python home being set incorrectly (i.e. at all)

@JacksonBurns
Copy link
Contributor Author

The RMG modules are built in place, which is why we need to set PYTHONPATH: https://stackoverflow.com/a/7851585

Maybe we also need to set the system path to point toward the libs in the conda environment?

@JacksonBurns
Copy link
Contributor Author

Intel Mac now fails only the tests that are due to the change in fork - why can't ubuntu see the libs? Going to set the library path for ld

@JacksonBurns
Copy link
Contributor Author

Current theory is that we have to set PYTHONPATH because we aren't actually installing rmgpy or arkane, just building them, so that Julia can see arkane and rmgpy during its installation process. But this then messes up the actual execution, since setting PYTHONPATH seems to mess up the normal path, making python unable to find its libs

Potential fix to this potential problem is to make the code actually installable

@JacksonBurns
Copy link
Contributor Author

@jonwzheng a familiar name has popped up on this PR:

E   ImportError: /home/runner/miniconda3/envs/rmg_env/lib/python3.9/site-packages/scipy/sparse/../../../../libstdc++.so.6: version `GLIBCXX_3.4.31' not found (required by /home/runner/miniconda3/envs/rmg_env/lib/python3.9/site-packages/rdkit/Chem/../../../../libboost_serialization.so.1.86.0)

@JacksonBurns
Copy link
Contributor Author

I have now confirmed that without installing Julia, the tests work. Something about installing juliaup and then RMS is causing python to be unable to find its libraries. Going to just printenv and see if juliaup is severely messing things up

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant