-
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
Strip Local version label (PEP 440) from Packages build from PackageInfo #4221
Conversation
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
The failures in CirrusCI look to be network driven. I don't think I changed anything there. Can I get someone to kick off the tests again to see if it's transitory? |
any news about this great fix? can help a lot when installing pytorch! |
@sdispater Maybe you can take a look at this PR to see? It looks like all the checks pass. |
Any updates on this fix? @sdispater @finswimmer |
This might fix pytorch issues, would be great to merge. @sdispater |
Any updates? Need to install pytorch too ... |
Installing packages like pytorch is not currently supported and there is no known timeline for support. FWIW this patch seemed to nearly get included in the last point release but then didn’t. if you need this feature urgently you could consider forking the poetry project repo and merging in the supporting pull request; the project from which the pull request came is nearly what you want, (although some URLs might need updating to install correctly.) The commenters in this pull request and in #2613 might possibly collaborate on maintaining that fork? |
tests/inspection/test_info.py
Outdated
@@ -225,3 +227,20 @@ def test_info_prefer_poetry_config_over_egg_info(): | |||
FIXTURE_DIR_INSPECTIONS / "demo_with_obsolete_egg_info" | |||
) | |||
demo_check_info(info) | |||
|
|||
|
|||
def test_info_public_version(): |
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.
I'd like to see these two combined into a parameterized test, and then this should be good to go.
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.
<mickey-mouse-voice>
I got three in one blow!</mickey-mouse-voice>
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.
Hate to do this to you @vedosis, but I think I might have overlooked some details in my earlier review. I'm wondering if we've considered the implications of a dependency requiring a +local_version
, or the user requiring one.
I think the design might need to be rethought -- namely, the version parsing/comparison code should be the right target. poetry-core
has a proper grammar for parsing versions, and modifications to the version comparison logic are likely to yield the best result.
Finally, I think that better testing is needed -- namely, we need to test what poetry does (or what is even expected) when nothing but +local_versions are available and the user requests none, requests one, and what happens when a dependency does the same.
Feel free to ask questions, work on this PR, or start a new one. I or @abn may give this a crack, but that is unlikely in the near future, so any interested parties are invited submit PRs along the lines of the above.
Well... that's disappointing. When I didn't get a response on the PR for a while, I moved on from So... I guess what I'm trying to say is... that's disappointing. I'm going to close this PR. If anyone else wants to pick up the |
The real issue here is there is no support for the level of metadata I think if we can come up with an expected set of behaviors we can improve the situation (e.g. keep poetry from uninstalling versions that only differ +locally) -- but there is no perfect solution possible (yet). |
The least we can do is not force update for eg: 1.10.0+cu113 -> 1.10.0 every time the dependency resolver runs. Simply stripping it like this PR does should be good enough according to PEP-440. As it stands it is simply impossible to use poetry if pytorch is installed in your environment. |
Is there any hope for this to ever get merged / solved? |
I doubt this will be fixed any time soon. Most of the potential champions have gotten discouraged and moved on, and those who remain are mostly wishing for it rather than pushing it forwards in code and committee meetings. The best option if you want multi-architecture poetry is still maintaining your own fork with this patch. (which btw is not that hard, if you want need to track poetry mainline.) I suspect that if a tech firm of some kind were invested in using poetry to manage their ML workflow this issue might get traction because developers could spend their work time on it. |
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. |
Resolves: #2613
Rebased into master i.l.o. 1.1 branch to avoid Python 2.7 (#4219)
RE: Documentation... I can't see anywhere the documentation would need to be updated. If it does, point me at it and I'll work it over.
New tests: