-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Update pipenv #12561
Update pipenv #12561
Conversation
Copyright policy changePlease note that on 2018-09-15 Trustees have approved new Gentoo copyright policy. All contributions made to Gentoo need to follow this policy. If you include the Signed-off-by line in your commit message, you indicate that you have read the policy and agree to its terms. For more detailed explanation, please see the new Gentoo copyright policy explained article. Pull Request assignmentSubmitter: @oz123 dev-python/parver: @bucefal91, @gentoo/proxy-maint Linked bugsNo bugs to link found. If your pull request references any of the Gentoo bug reports, please add appropriate GLEP 66 tags to the commit message and request reassignment. If you do not receive any reply to this pull request, please open or link a bug to attract the attention of maintainers. In order to force reassignment and/or bug reference scan, please append Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide |
QA is broken, because it's checking without the previous commit. If the complete branch is complete branch is merged the build should work. |
No, it's broken because you added python3.7 support to pipenv while parver doesn't have it. So required dependency can't be fulfilled. This error would've been detected by repoman, and I thought repoman stopped committing if it. Judging from the message box you seem to be using repoman to commit so it's a bit weird it let it through :P |
1ba68e4
to
723821c
Compare
Yes indeed. Upstream metadata didn't specify it. But apparently their CI already test python 3.7 and he ebuild runs find (also with tests activated) for python3.7 in gentoo so I now added it. |
Could you double-check this? Rest looks good to me, tests run etc. Let's wait for @gentoo/python and @bucefal91 to comment. |
Oh, sorry, I forgot to updated the Manifest file. It's now updated. |
Hey, sorry it's taken so long. I'm not sure do I want to commit on behalf of @gentoo/python since the changed versioning of pipenv. I see it follows upstream, but if python project has some other plans... Could you create a bug about bumping it, then link your PR to that bug? To possibly get a note from python project about what they think about it. |
@juippis I am not sure it's worth the effort. It seems that pipenv is dead. |
pipenv isn't dead, they have an issue open that asked if they are dead and they said they are not. They apparently were blocked on some lower level things. Another release is expected soon. |
Related: pypa/pipenv#4058 (comment) |
They put |
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.
@oz123 I had a closer look at pipenv ebuild dependencies and found some potential issues:
-
missing in ebuild? (found in
setup.py
)"certifi",
"virtualenv-clone>=0.2.5",
"virtualenv",
'enum34; python_version<"3"',
'typing; python_version<"3.5"'
-
can be dropped from ebuild, seems unused?
>=dev-python/flake8-3.0.0[${PYTHON_USEDEP}]
>=dev-python/pew-0.1.26[${PYTHON_USEDEP}]
-
needs moving to
DEPEND
? (because of use insetup_requires
, so build time)dev-python/invoke[${PYTHON_USEDEP}]
>=dev-python/parver-0.2[${PYTHON_USEDEP}]
Also, I wonder if we should patch away folder pipenv/vendor/
now, later, or not.
PS: Please squash the second parver commit into the first one.
@hartwork thanks for getting back to me on this. I added your suggestions, and removed what needed to be removed. |
On a side note I find that |
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.
Thank you!
I stumbled upon one (hopefully last) little thing we'll still need to fix with parver: It's that setup.py
contains ~=
version constructs like 'arpeggio ~= 1.7'
. That translates to >=1.7
but also <2
( technically ==1.7.*
). The <2
is trouble on Gentoo level because it will (first start crashing after updates and then) keep users in the past even if parver turns out to be fine with that version in the future. (This is somewhat similar to what we have with dockier-compose.)
So the fix would be to
- patch all the
~=
insetup.py
into>=
- turn (at least)
dev-python/arpeggio[${PYTHON_USEDEP}]
into>=dev-python/arpeggio-1.7[${PYTHON_USEDEP}]
(because we still do have1.5
around)
What do you think?
Package-Manager: Portage-2.3.79, Repoman-2.3.16 Signed-off-by: Oz Tiram <oz.tiram@gmail.com>
Package-Manager: Portage-2.3.79, Repoman-2.3.16 Signed-off-by: Oz Tiram <oz.tiram@gmail.com>
Sounds like a plan and I pushed a set of changes implementing what you suggested. |
to update pipenv I needed also to update the dependecies (added invoke) and bump the version of parver.