Skip to content

Poetry won't install 'wheel' package (1.0.10 -> 1.1.0 regression) #3075

Closed
Closed
Poetry won't install 'wheel' package (1.0.10 -> 1.1.0 regression)#3075
Labels
kind/bugSomething isn't working as expected

Description

@brechtm
brechtm
opened on Oct 4, 2020

  • I am on the latest Poetry version.

  • I have searched the issues of this repo and believe that this is not a duplicate.

  • (N/A) If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

  • OS version and name: Linux, MacOS, Windows

  • Poetry version: 1.1.0

  • Link to your pyproject.toml file: brechtm/rinohtype/pyproject.toml

Issue

Since updating to 1.1.0, Poetry will no longer install the wheel dependency. See the "Install development dependencies" section of any "unit tests (wheel)" jobs on rinohtype's CI tests. After creating a new virtual environment, instead of installing wheel, Poetry prints:

 • Removing wheel (0.34.2)

I can reproduce this locally. Removing and adding 'wheel' manually does not help.

Activity

  1. brechtm
    added
    kind/bugSomething isn't working as expected
    status/triageThis issue needs to be triaged
    on Oct 4, 2020

  2. abn commented on Oct 4, 2020

    @abn
    abn
    on Oct 4, 2020
    Member

    @brechtm this was an intentional change introduced via b92e681 since it is currently a base package in virtual environments. The removal seems to happen because it is removed from the lock, since it is now an unsafe package. I need to check if we can make it safe without impacting anything.

    The CI jobs you pointed to indicate the use of poetry run python setup.py bdist_wheel. I am also a bit confused as to why the project uses both setuptools and poetry together. If you drop by the discord sover, I'd like to know more about your use case.

  3. brechtm commented on Oct 4, 2020

    @brechtm
    brechtm
    on Oct 4, 2020
    Author

    @brechtm this was an intentional change introduced via b92e681 since it is currently a base package in virtual environments.

    What does it mean that wheel is a base package in virtual environments? That sounds like it is always available, without the need to install it. However, after a poetry install using 1.1.0, wheel is not installed in the venv (poetry run pip list | grep wheel).

    After a poetry update (updates virtualenv and tqdm), wheel is still not installed. Only after deleting the venv and another poetry install, wheel is installed.

    The CI jobs you pointed to indicate the use of poetry run python setup.py bdist_wheel. I am also a bit confused as to why the project uses both setuptools and poetry together. If you drop by the discord sover, I'd like to know more about your use case.

    I simply haven't investigated converting from setup.py yet, because it includes custom code to determine the version number from git. I'm sure this is over-complicating things, but that is how it is at the moment. I now use Poetry just to set up the development venv.

  4. brechtm
    added a commit that references this issue on Oct 4, 2020

    Recover from an issue with Poetry 1.1.0

    ac07f5d

  5. abn commented on Oct 4, 2020

    @abn
    abn
    on Oct 4, 2020
    Member

    Only after deleting the venv and another poetry install, wheel is installed.

    That is what I would expect if you were using a cached venv created prior to 1.1.0. The change in #2666 means that now we use virtualenv to create the environment, this will install pip, setuptools and wheel. Dropping wheel from pyproject.toml and regenerating the lock file, and also the enviornment should fix your issue. Wheel should be available in the environments created by 1.1.0.

    I will take a look to see if we "really" need wheel to be marked unsafe. But I suspect we will since otherwhise wheel building for sdist dependencies might fail today in certain scenarios.

  6. glenjarvis
    added a commit that references this issue on Oct 5, 2020

    Wheel dependency does not export

    eb11d4f

  7. brechtm commented on Oct 5, 2020

    @brechtm
    brechtm
    on Oct 5, 2020
    Author

    That is what I would expect if you were using a cached venv created prior to 1.1.0.

    Note that the issue was not fixed by deleting the venv and then doing a poetry install. In the CI jobs I referenced above the cached venv was not restored (because poetry.lock was changed), so these were also fresh installs.

  8. pmantica1 commented on Oct 19, 2020

    @pmantica1
    pmantica1
    on Oct 19, 2020

    I think that what led to the:Removing wheel (0.34.2) line was that the poetry.lock file was generated using a old version of poetry. The version of poetry in the CI was probably the latest version of poetry, in which the wheel package was unsafe. Since this package is marked as unsafe in the latest version of poetry, the poetry in the CI decided to remove it. However, I think that most if not all of the unsafe packages, e.g. pip, setuptools and wheels, are by default included in a python virtualenv. (See link below). So arguably the right behavior for poetry here would be to remove these packages from the poetry.lock file without uninstalling them. Thoughts?

    https://packaging.python.org/tutorials/installing-packages/#creating-virtual-environments

  9. brechtm commented on Oct 20, 2020

    @brechtm
    brechtm
    on Oct 20, 2020
    Author

    So arguably the right behavior for poetry here would be to remove these packages from the poetry.lock file without uninstalling them. Thoughts?

    For what it's worth, I don't think a fix for this should be high priority as it will only occur in a very specific situation. The problem can be manually fixed without too much fuss and there are probably more urgent issues to address.

    For anyone running into the same problem, this should fix it:

    • delete your virtual environment
    • poetry install using 1.1.x
    • poetry update
    • delete the new virtual environment
    • poetry install again

  10. pmantica1 commented on Oct 20, 2020

    @pmantica1
    pmantica1
    on Oct 20, 2020

    Yep you are right. It's probably not worth fixing this.

  11. laggardkernel commented on Jul 1, 2021

    @laggardkernel
    laggardkernel
    on Jul 1, 2021

    Update: seems my problem is unrelated, I'd better switch to psycopg2-binary.

    psycopg2 depends on wheel to avoid building the package from source. wheel does exist in poetry.lock and pyproject.toml. But during creating the environment, pip tells me wheel is not installed.

    Package operations: 82 installs, 0 updates, 1 removal, 2 skipped

  • Removing wheel (0.34.2)
...
  • Installing psycopg2 (2.8.5): Failed

  EnvCommandError

  Command ['/Users/username/.local/share/pyenv/versions/search-spider-tC2SZ2ft-py3.7/bin/pip', 'install', '--no-deps', '/Users/username/Library/Caches/pypoetry/artifacts/43/1e/47/e00cc30663ca574d30900f282f4d8dbde97c45de8357536fbef7589179/psycopg2-2.8.5.tar.gz'] errored with the following return code 1, and output:
  Processing /Users/username/Library/Caches/pypoetry/artifacts/43/1e/47/e00cc30663ca574d30900f282f4d8dbde97c45de8357536fbef7589179/psycopg2-2.8.5.tar.gz
  Using legacy 'setup.py install' for psycopg2, since package 'wheel' is not installed.
  Installing collected packages: psycopg2
      Running setup.py install for psycopg2: started
      Running setup.py install for psycopg2: finished with status 'error'
      ERROR: Command errored out with exit status 1:

    Why does poetry keep removing wheel even it's defined in poetry.lock and pyproject.toml?

    Now I'm not able to build the virtual environment.

  12. abn commented on May 12, 2022

    @abn
    abn
    on May 12, 2022
    Member

    This should not happen with 1.2.

    $ poetry remove wheel
Updating dependencies
Resolving dependencies... (0.1s)

Writing lock file

Package operations: 0 installs, 0 updates, 1 removal

  • Removing wheel (0.37.1)
$ poetry add wheel
Using version ^0.37.1 for wheel

Updating dependencies
Resolving dependencies... (0.1s)

Writing lock file

Package operations: 1 install, 0 updates, 0 removals

  • Installing wheel (0.37.1)
  13. abn
    closed this as completedon May 12, 2022
  14. mkniewallner
    removed
    status/triageThis issue needs to be triaged
    on Jun 11, 2022

  15. github-actions commented on Mar 1, 2024

    @github-actions
    github-actionsBot
    on Mar 1, 2024 – with GitHub Actions

    This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

  16. github-actions
    locked as resolved and limited conversation to collaborators on Mar 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/bugSomething isn't working as expected

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions