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

Outdated metadata after version bump for local package #3289

Closed
3 tasks done
peldszus opened this issue Oct 26, 2020 · 15 comments · Fixed by #3900
Closed
3 tasks done

Outdated metadata after version bump for local package #3289

peldszus opened this issue Oct 26, 2020 · 15 comments · Fixed by #3900
Labels
kind/bug Something isn't working as expected

Comments

@peldszus
Copy link
Contributor

peldszus commented Oct 26, 2020

  • I am on the latest Poetry version.

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

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

  • OS version and name: Ubuntu 18.04.1

  • Poetry version: 1.1.4

  • Python version: I tested this in the following python environments:

    • 3.7.5 (using importlib_metadata)
    • 3.8.0
    • 3.8.6
  • Link of a Gist with the contents of your pyproject.toml file:

Issue

When I build and install my package, bump the version, then build and install again, the metadata of the package is not always showing the right version, but an older version number. It works for the first version bump, but fails for further.

I am not sure whether this is doe to the way poetry installs the package, or whether this is a bug in importlib.

Step 1: Bump the version

$ poetry version patch
Bumping version from 0.1.1 to 0.1.2

Step 2: Build and install the package

$ poetry install -vvv --no-dev
...
Installing the current project: pi (0.1.2)
  - Building package pi in editable mode
  - Adding pi.pth to /tmp/test/folder/env/lib/python3.8/site-packages for /tmp/test/folder
  - Adding the pi-0.1.2.dist-info directory to /tmp/test/folder/env/lib/python3.8/site-packages

Step 3: Check the metadata

$ python -c "from importlib.metadata import version; print(version('pi'))"
0.1.1

This should be 0.1.2, not 0.1.1.

To reproduce this, please have a look at the gist.

@peldszus peldszus added kind/bug Something isn't working as expected status/triage This issue needs to be triaged labels Oct 26, 2020
@sinoroc
Copy link

sinoroc commented Oct 26, 2020

Would you mind finding the site-packages directory for your environment, and see if you can find a pi-0.1.1.dist-info directory in there?

@peldszus
Copy link
Contributor Author

Sure!

$ ls /tmp/test/folder/env/lib/python3.8/site-packages/pi-*
/tmp/test/folder/env/lib/python3.8/site-packages/pi-0.1.0.dist-info:
INSTALLER  METADATA  RECORD

/tmp/test/folder/env/lib/python3.8/site-packages/pi-0.1.1.dist-info:
INSTALLER  METADATA  RECORD

/tmp/test/folder/env/lib/python3.8/site-packages/pi-0.1.2.dist-info:
INSTALLER  METADATA  RECORD

@peldszus
Copy link
Contributor Author

PS:

I should add that the metadata are correctly shown when I reset my venv in between.

Following my gist: When I do make clean build test after the failure, the correct version number is shown. Most likely because I then have in my fresh venv's site-packages only the lastest pi-0.1.2.dist-info folder and no distracting other versions.

@sinoroc
Copy link

sinoroc commented Oct 26, 2020

There should be only one of those dist-info directory per project. That might be the reason why importlib.metadata gets confused. What does pip show pi say? poetry version?

@peldszus
Copy link
Contributor Author

Both correctly say 0.1.2. But, importlib.metadata still finds 0.1.1.

@sinoroc
Copy link

sinoroc commented Oct 26, 2020

In the end it does not matter much what pip or importlib.metadata say. I am pretty sure there should be only one dist-info directory per project. Looks like a bug to me.

If you delete the superfluous dist-info directories, everything is back to normal, right?

@peldszus
Copy link
Contributor Author

Yes.

This is equivalent to the effect of installing to a clean env, that I mentioned above.

@peldszus
Copy link
Contributor Author

I didn't have much time to look into, but it seems there is code to remove the old dist-info directory, it just didn't trigger. I also didn't see the corresponding debug message in my output.

@sinoroc
Copy link

sinoroc commented Oct 27, 2020

@peldszus Looks to me like this piece of code would delete a pre-existing dist-info for the exact same version number. It does not seem to be looking for dist-info with different version numbers (lower or higher).

@peldszus
Copy link
Contributor Author

You're right, only the exact same version is removed, not older or newer ones. When initially looking at this code I got tricked by the for-loop into thinking it is iterating over all matching versions.

I propose to rename this issue into: "Existing dist-info of different versions are not removed from site-packages for local build".

@finswimmer
Copy link
Member

I guess #2855 is related, is it?

@peldszus
Copy link
Contributor Author

I guess #2855 is related, is it?

Yes, indeed. 👍

And I won't rename this issue here, because the related #2918 is already exactly stating what I would have changed for.

@peldszus
Copy link
Contributor Author

Looks like #3900 will fix this.

@abn
Copy link
Member

abn commented Apr 14, 2021

Resolved by: #3900

Copy link

github-actions bot commented Mar 2, 2024

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 2, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/bug Something isn't working as expected
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants