-
-
Notifications
You must be signed in to change notification settings - Fork 608
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
Run pip-compile in env python rather than pip-tools python #1998
base: main
Are you sure you want to change the base?
Conversation
I just remembered, I think it could be considered avoiding a python-specific virtual environment employing the feature proposed in #1898. What do you think? |
OK, so a few things here: It's not possible to run We just essentially need pip-tools installed in I did consider leveraging Regarding #1898 : That could indeed be a better solution. I wasn't aware |
Yes, sounds good! I'll try to get that pull request merged soon so you can rebase. |
One question is what to do with the version in the output header. With the change in #1898 we could get a header like:
Which is OK I suppose because the python version is explicit (even if the Python 3.11 bit is now irrelevant). But if we change it automatically I suppose we should change that header to say it was run with the |
Well, the header is generated in the Lines 122 to 128 in 65b0d36
We could pass a reference to the target python to the output writer in the compile script by a new parameter, instead of requesting the |
Yes, I think given that pip can essentially do what we need now (since last year it seems) the solution in this PR is no longer necessary. I will rewrite it soon. I do wonder if we can get the Python version without resorting to a subprocess call ourselves, though. Perhaps it can be queried via |
@georgek I'm inclined to revive the PR at its current state, as it seems there is no other possibility right now. Efforts to decouple from |
CI is unfortunately failing on Windows right now, and I don't run that... |
Me neither. I don't have much time to work on this right now, unfortunately, but it's on my todo list. If nobody else can figure it out first I'll try to find a Windows box to test it on at some point. |
Resolves #1087
Usually pip-tools is installed inside a project env and run from there. So it gets run in the same version of Python that the project is developed with. This doesn't work if pip-tools is installed somewhere else, like when installed with pipx.
The change here detects whether the currently running Python is different to the one on the PATH. Such a mismatch would probably always lead to unexpected behaviour. So in that case it creates a temporary venv with the Env Python, installs pip-tools, and runs it again there.
This approach could also be modified to allow a
python_executable
to be passed explicitly (and falling back to PATH by default), similar to howpip-sync
is now. One could generated requirements file for multiple versions of Python (of course, you could already do it with tox, but this gives another option).There are still some TODOs:
pip-sync
(it already takespython_executable
option, but can use env Python if not given),Finally, this is technically a breaking change. It's intended to resolve the
pipx
scenario (or even installed with OS package manager). I can't think of any reason why anyone would want pip-tools to run on an interpreter other than the one in the current env, but it will probably still break someone's workflow...Contributor checklist
Maintainer checklist
backwards incompatible
,feature
,enhancement
,deprecation
,bug
,dependency
,docs
orskip-changelog
as they determine changelog listing.