-
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
Version Matching - Local Identifiers #6570
Comments
You might need to be more specific about the issue you're running into -- at least I am having a hard time following. It sounds like the lock file is recording a garbage version -- could you please post the expected lock file entry and the actual lock file entry, as well as describe concrete versions so people can understand where they are incorrect? |
Thanks, and sorry about that.
When adding Actual Lock File Entry
Expected Lock File Entry
We are using the short git commit hash for development builds. |
I don't think this is a bug -- they are the same version and according to PEP 440/Poetry's internal logic, are treated as equivalent when you ask for a global version. Local versions are really just informational tags appended to the end of a version in other words -- you can request them specifically, but when you ask for a global version, they are not different versions as far as satisfying version constraints is concerned. Their intended use is to signify that they may contain code different from an 'upstream' version -- in this case Poetry considers them interchangeable as both versions claim to provide '0.92.0'. You likely want to tag your builds as prerelease if you are providing development builds, e.g. I think we've done our best to call this out in the docs, but maybe it could be made clearer -- feedback on where you looked and how we can make this digestible would be welcome. |
https://www.python.org/dev/peps/pep-0440/#version-matching Doesn’t the version matching section of PEP440 state they should be treated as different versions? The examples in issue #4729 that is indicated as a bug seem to also indicate the versions should be treated as distinct. |
That is correct in the local -> global direction, but as I understand your issue (you're getting local versions when you don't request them), you're talking global -> local. If you request |
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. |
-vvv
option) and have included the output below.Issue
I believe this issue is similar to #4729 but didn't consider it a duplicate because the issue is marked as closed.
This issue might be fixed up:
python-poetry/poetry-core#379
On version 1.1.13 adding a dependency to the pyproject.toml would always result in that specific version being written to the
poetry.lock
when runningpoetry lock --no-update
.After upgrading to
1.2.1
we noticed that adding a pinned version of an internal library to thepyproject.toml
file and runningpoetry lock --no-update
would result in the lock file containing a pointer to the expected version, but it would include the local identifier.The
poetry.lock
would look like the example below.A workaround that we found was adding the source to the
pyproject.toml
. Package versions with local identifiers are published to thelocal-pypi-snapshot
PyPI instance and versions without are published tolocal-pypi-release
.The text was updated successfully, but these errors were encountered: