-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Drop poetry's dependency on pip and setuptools in project virtual environment #2826
Conversation
76d47e7
to
708ce02
Compare
07b8a15
to
63ffa17
Compare
a5ea0fa
to
489359a
Compare
Some sort of approach to let me lock |
We are dealing with exactly the same issue using pipenv, it always wants the latest version even if it breaks something. Please ensure at least to let the ability of user to freeze the version somehow. Ideally yes, it would use its own, independent setuptools/wheel, but for some complex projets that needs certain version of setuptools, especially with the version 50.x breaking much stuff with pyinstaller packaging, I am looking to a better alternative than |
@gsemet can you provide a bit more context please? This change only means that poetry's use is isolated to specific versions of pip/setuptools and decoupled. If your project depends on it, you can specify it as either a |
Yes, this change is actually what i would to see. I am using poetry on my newer projects and does not face yet this issue I have on older projects still using pipenv. Pipenv always updates to the latest setuptools available on pypi within the project's virtualenv (also So yes, I am pretty much very interesting is seeing the right behavior in poetry, and maybe it already does it: poetry either vendors its own setuptools/wheel package so that they change with poetry updates, but if my package wants some specific version of setuptools for any reason, it should not cause any incompatibility with poetry. From out point of view, TL;DR: I need to update to poetry, it seems like you already do the right thing :) |
@gsemet ah, I think I misunderstood your first message. Glad that this is something that is useful. However, do note that This is what I (putting on my poetry user hat), want to change in this PR. Poetry (putting on my maintainer hat again), has been gradually reducing reliance on |
So, I hope this PR lands in the next version of poetry :) |
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.
@abn Looking mostly good so far. I have left a few question, would be glad if you could get back on those.
Use embedded pip wheel from virtualenv package. This avoids the need for pip to be a critical package in the project's virtual environment.
Well, not really, since That's why I said it's no small task to make it |
It seems as if https://github.com/pypa/build would be a EDIT:// That might have been to fast: https://github.com/pypa/build/blob/main/src/build/env.py#L157-L168 |
At present it does use That said, if we do have support for wheel installations, and access to |
You don't actually override pypa/build's env-setup, since the caller is the one calling it, i.e. pip is only sub-called by
So you just want to create a venv with the necessary dependencies yourself, and do this (
So for Poetry, I expect that if we want to use pypb/build, we just populate a venv as we do now, and use pypa/build's This also puts Poetry directly in control of whether it uses a single scratch venv to build all necessary wheels for the "real" project venv, or uses an isolated venv for each wheel, or some other combination thereof. |
I'm eagerly awaiting this change as a resolution to #1584. When do people expect this PR to be included in a release? |
@bmw the next planned release is pipx install --force --suffix=@master 'poetry @ git+https://github.com/python-poetry/poetry.git@master' |
This change introduces the following configuration options: - `virtualenvs.options.no-pip` (Default: `false`) - `virtualenvs.options.no-wheel` (Default: `false`) - `virtualenvs.options.no-setuptools` (Default: `false`) With these options, we allow, the user to control the inclusion of `pip`, `wheel` and `setuptools` packages in new virtual environments. The defaults used retain existing behaviour as of `1.1.5`. In addition the following now holds true. - projects can define `pip`, `wheel` and `setuptools` as dependencies - if any of these packages are in the project's dependency tree, poetry will manage their versions - all poetry internal commands will use pip embedded in virtualenv irrespective of pip beig available in the environment - if `poetry run pip` is executed, pip installed in the virtualenv will be prioritsed - `poetry install --remove-untracked` will ignore these packages if they are not present in the project's dependency tree Relates-to: python-poetry#2826 Relates-to: python-poetry#3916
This change introduces the following configuration options: - `virtualenvs.options.no-pip` (Default: `false`) - `virtualenvs.options.no-wheel` (Default: `false`) - `virtualenvs.options.no-setuptools` (Default: `false`) With these options, we allow, the user to control the inclusion of `pip`, `wheel` and `setuptools` packages in new virtual environments. The defaults used retain existing behaviour as of `1.1.5`. In addition the following now holds true. - projects can define `pip`, `wheel` and `setuptools` as dependencies - if any of these packages are in the project's dependency tree, poetry will manage their versions - all poetry internal commands will use pip embedded in virtualenv irrespective of pip beig available in the environment - if `poetry run pip` is executed, pip installed in the virtualenv will be prioritsed - `poetry install --remove-untracked` will ignore these packages if they are not present in the project's dependency tree Relates-to: python-poetry#2826 Relates-to: python-poetry#3916
This change introduces the following configuration options: - `virtualenvs.options.no-pip` (Default: `false`) - `virtualenvs.options.no-wheel` (Default: `false`) - `virtualenvs.options.no-setuptools` (Default: `false`) With these options, we allow, the user to control the inclusion of `pip`, `wheel` and `setuptools` packages in new virtual environments. The defaults used retain existing behaviour as of `1.1.5`. In addition the following now holds true. - projects can define `pip`, `wheel` and `setuptools` as dependencies - if any of these packages are in the project's dependency tree, poetry will manage their versions - all poetry internal commands will use pip embedded in virtualenv irrespective of pip beig available in the environment - if `poetry run pip` is executed, pip installed in the virtualenv will be prioritsed - `poetry install --remove-untracked` will ignore these packages if they are not present in the project's dependency tree Relates-to: python-poetry#2826 Relates-to: python-poetry#3916
This change introduces the following configuration options: - `virtualenvs.options.no-pip` (Default: `false`) - `virtualenvs.options.no-wheel` (Default: `false`) - `virtualenvs.options.no-setuptools` (Default: `false`) With these options, we allow, the user to control the inclusion of `pip`, `wheel` and `setuptools` packages in new virtual environments. The defaults used retain existing behaviour as of `1.1.5`. In addition the following now holds true. - projects can define `pip`, `wheel` and `setuptools` as dependencies - if any of these packages are in the project's dependency tree, poetry will manage their versions - all poetry internal commands will use pip embedded in virtualenv irrespective of pip beig available in the environment - if `poetry run pip` is executed, pip installed in the virtualenv will be prioritsed - `poetry install --remove-untracked` will ignore these packages if they are not present in the project's dependency tree Relates-to: python-poetry#2826 Relates-to: python-poetry#3916
This change introduces the following configuration options: - `virtualenvs.options.no-pip` (Default: `false`) - `virtualenvs.options.no-wheel` (Default: `false`) - `virtualenvs.options.no-setuptools` (Default: `false`) With these options, we allow, the user to control the inclusion of `pip`, `wheel` and `setuptools` packages in new virtual environments. The defaults used retain existing behaviour as of `1.1.5`. In addition the following now holds true. - projects can define `pip`, `wheel` and `setuptools` as dependencies - if any of these packages are in the project's dependency tree, poetry will manage their versions - all poetry internal commands will use pip embedded in virtualenv irrespective of pip beig available in the environment - if `poetry run pip` is executed, pip installed in the virtualenv will be prioritsed - `poetry install --remove-untracked` will ignore these packages if they are not present in the project's dependency tree Relates-to: python-poetry#2826 Relates-to: python-poetry#3916
For project virtual environments, default to enabling pip, setuptools and wheel packages to retain existing stable behaviour to prevent unexpected breakages caused by development environments making assumptions of base package availability in virtual environments. Poetry itself does not require the use of these packages and will execute correctly within environments that do not have these packages. This change retains the ability to manage these packages as direct project dependency as introduced in python-poetry#2826. All poetry internal execution of pip is retaining the use of the wheel embedded within the virtualenv package used by poetry. In cases where a one of these reserved packages are being managed as a project dependency, the will be treated as any other project dependency. Executing `poetry install --remove-untracked` will not remove any of these reserved packages. However, `poetry add pip` and `poetry remove pip` will trigger the update and removal of `pip` respectively. Relates-to: python-poetry#2826 Relates-to: python-poetry#3916
For project virtual environments, default to enabling pip, setuptools and wheel packages to retain existing stable behaviour to prevent unexpected breakages caused by development environments making assumptions of base package availability in virtual environments. Poetry itself does not require the use of these packages and will execute correctly within environments that do not have these packages. This change retains the ability to manage these packages as direct project dependency as introduced in python-poetry#2826. All poetry internal execution of pip is retaining the use of the wheel embedded within the virtualenv package used by poetry. In cases where a one of these reserved packages are being managed as a project dependency, the will be treated as any other project dependency. Executing `poetry install --remove-untracked` will not remove any of these reserved packages. However, `poetry add pip` and `poetry remove pip` will trigger the update and removal of `pip` respectively. Relates-to: python-poetry#2826 Relates-to: python-poetry#3916
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
An initial attempt at using the embedded pip wheel from virtualenv package directly. This avoids the need for any critical packages in the project's virtual environment.
Resolves: #1584
Testing this pull request
Since this is a fundamental shift in how we setup virtual environments, testing a broad range of use cases would be great.
Using pipx
pipx install --suffix=@2826 'poetry @ git+https://github.com/python-poetry/poetry.git@refs/pull/2826/head'
Once this is done, you can use this version of poetry as shown here.
poetry@2826 new foobar pushd foobar poetry@2826 add pycowsay poetry@2826 run pycowsay
If you want to do a
pip list
, there exists a convinience wrapper that will use the embeddedpip
if the environment does not contain one.You will notice here that none of
wheel
,setuptools
norpip
exists in the virtual environment.Using a container (podman | docker)