Bug 1324372 - Please update python-virtualenv to at least 13.1
Summary: Please update python-virtualenv to at least 13.1
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: python-virtualenv
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Steve Milner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-06 08:09 UTC by Dmitry Tantsur
Modified: 2016-04-06 09:29 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-04-06 08:30:28 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Dmitry Tantsur 2016-04-06 08:09:45 UTC
Description of problem:
OpenStack actively uses pip -c flag [1] for controlling dependencies for its tests. However, the current virtualenv in Fedora 23 embeds pip 6.0.8 which does not support it. Meaning, that all people working on OpenStack on Fedora will have to update virtualenv itself via "sudo pip install". I wonder if it's possible to provide a system update to at least 13.1 (featuring pip 7.1) [2].

Thanks!

[1] https://pip.pypa.io/en/stable/user_guide/#constraints-files
[2] https://virtualenv.pypa.io/en/latest/changes.html#id11

Comment 1 Matthias Runge 2016-04-06 08:30:28 UTC
Upgrading in a released version is not acceptable by update policy.
Fedora 24 contains virtualenv-14.0

dnf --releasever=24 update python-virtualenv will pull that specific package (and dependencies) from f24 repositories.

Comment 2 Dmitry Tantsur 2016-04-06 08:34:56 UTC
Could you point me to this update policy banning virtualenv? Cause other packages easily upgrade on a released version, even bumping major version.

Comment 3 Matthias Runge 2016-04-06 08:44:28 UTC
ah, sorry.
https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases

Comment 4 Dmitry Tantsur 2016-04-06 08:46:55 UTC
I don't see an explicit "no never" in this link, but I guess I can't argue. It's just sad for me to redirect people to ubuntu as OpenStack development platform again...

Comment 5 Felix Schwarz 2016-04-06 08:47:54 UTC
(In reply to Dmitry Tantsur from comment #2)
> Could you point me to this update policy banning virtualenv? Cause other
> packages easily upgrade on a released version, even bumping major version.

I guess it also depends on the maintainer(s) - sometimes they feel that the fallout of a major upgrade is manageable while others try stay on the safe side. E.g. ansible recently got upgraded to 2.0 in Fedora (and so far it works for me without any problems). Other times we're not so lucky (e.g. botched hamster 2.0 upgrade in F23) so being cautious on major upgrades seems to a be a good thing.

Comment 6 Dmitry Tantsur 2016-04-06 08:51:19 UTC
Also note that we have inconsistency between shipped pip's: system on is 7.1 (which works), virtualenv one is 6.0.8.

Comment 7 Matthias Runge 2016-04-06 09:25:21 UTC
@dmitry: it's mentioned in https://fedoraproject.org/wiki/Updates_Policy#Beta_to_Pre_Release

* Avoid Major version updates, ABI breakage or API changes if at all possible. 

https://fedoraproject.org/wiki/Updates_Policy#Philosophy

mentions this as well:
... As a result, we should avoid major updates of packages within a stable release.

Comment 8 Dmitry Tantsur 2016-04-06 09:29:12 UTC
I don't think virtualenv follows semver (like Firefox), so I don't think this applies.

Major version bump seems to designate updating of bundled libraries to major versions. In 13.1 these are: pip to 7.1.0, setuptools to 18.0.1. In Fedora we have (surprise!) pip 7.1.0, setuptools 18.0.1. So we should have had virtualenv 13.1 to avoid confusion.


Note You need to log in before you can comment on or make changes to this bug.