Bug 1324372

Summary:	Please update python-virtualenv to at least 13.1
Product:	[Fedora] Fedora	Reporter:	Dmitry Tantsur <dtantsur>
Component:	python-virtualenv	Assignee:	Steve Milner <smilner>
Status:	CLOSED CANTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	23	CC:	fschwarz, mhayden, mrunge, mstuchli, smilner
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-04-06 08:30:28 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

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.