-
Notifications
You must be signed in to change notification settings - Fork 188
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
Support virtual environment #578
Conversation
f60bae3
to
df1ef06
Compare
Since this is useful outside PyCall testing, I included this functionality in python_cmd function instead of inlining it to the test.
I added some tests and they all pass on CIs now. I think it's good to go. (But please review.) |
Codecov Report
@@ Coverage Diff @@
## master #578 +/- ##
==========================================
- Coverage 53.11% 52.45% -0.66%
==========================================
Files 19 19
Lines 1525 1567 +42
==========================================
+ Hits 810 822 +12
- Misses 715 745 +30
Continue to review full report at Codecov.
|
I'm trying to run the change 05877b9 on AppVeyor but it's not get triggered... (Tried re-open and force-push) |
* `venv` support is now properly tested. This finds a bug in `pythonhome_of`: `sys.base_prefix` should be used instead of `sys.prefix` (same for `sys.base_exec_prefix`). * The path to Python executable passed to `pythonhome_of` was ignored when `python_cmd` was introduced. This is fixed now. * Use `python_cmd` in `find_libpython`. This properly sets `PYTHONIOENCODING`.
if hasattr(sys, "base_exec_prefix"): | ||
sys.stdout.write(sys.base_prefix) | ||
sys.stdout.write(":") | ||
sys.stdout.write(sys.base_exec_prefix) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like we should be using sys.base_prefix
and sys.base_exec_prefix
instead of sys.prefix
and sys.exec_prefix
to support venv
. With this change, this PR (accidentally) solves #410 as well. The reason is commented just below: 9dde9a8#diff-d16c3d4423fa5349bf01729c8beea4cdR90
@stevengj I think it's good to go, unless you want to bikeshed the environment variable names |
Resolved conflicts due to: 45cbcee (drop 0.6 support)
Should it be documented in the README? |
Sure, I added a section in README. preview: https://github.com/tkf/PyCall.jl/tree/venv#python-virtual-environment |
# Fix the environment for running `python`, and setts IO encoding to UTF-8. | ||
# If cmd is the Conda python, then additionally removes all PYTHON* and | ||
# CONDA* environment variables. | ||
function pythonenv(cmd::Cmd) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't it sufficient to just run python -E
to ignore PYTHON*
? Why do we need to remove CONDA*
since we are not running conda
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I guess we don't want to ignore these variables for non-Conda Python.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pythonenv
is just moved from build.jl
to depsutils.jl
to make it usable at runtime.
Why doesn't it work for Conda environments? |
Each conda environment has its own copy of |
Thaaaaanks!!! 🎉 |
@tkf Do you know whether this would work with poetry? I'm running into the same issues about incompatible Edit: I was able to fix it. In case someone is hitting a similar issue: The poetry environment that I setup was using a python binary build via python-build and by default those binaries don't come with a shared object. I had to explicitly build with |
This PR grew out of a small feature addition to a patch that includes a few more. Here is a new summary:
PYCALL_JL_RUNTIME_PYTHON
(andPYCALL_JL_RUNTIME_PYTHONHOME
).ImportError: No module named 'encodings'
when using with virtualenv + python3 #410: Support building Pycall against a Python executable generated bypython -m venv
.Py_SetPythonHome
andPy_SetProgramName
areccall
ed with and withoutPYCALL_JL_RUNTIME_PYTHON
.wpyprogramname
andwPYTHONHOME
are removed.Original summary:
I suggest to let users control Python environment at runtime by (say)
ENV["PYCALL_JL_RUNTIME_PYTHON"]
(andENV["PYCALL_JL_RUNTIME_PYTHONHOME"]
). This can be used to make sure that Julia and Python environments for a project are fully reproducible. CombiningPkg3.jl
andpipenv
, a typical usage would be very simple: