On 03/16/2015 08:32 PM, Robert Collins wrote: > On 17 March 2015 at 13:22, Doug Hellmann <[email protected]> wrote: >> Excerpts from Robert Collins's message of 2015-03-17 12:54:00 +1300: >>> I've raised this in reviews 157135 and 153966, but I think it deserves >>> a thread of its own. >>> >>> I think universal wheels are useful - they are simple to build and >>> publish - we don't need to do one wheel per Python version. >>> >>> However, right now I'm fairly sure that we're not exporting the >>> requirements from requirements-py2 / requirements-py3 as environment >>> markers (see PEP-426). >>> >>> That means that a wheel built on Python2 for a pbr project using >>> requirements-pyN files, even if marked as a universal wheel, will only >>> have the requirements for the Python2 deps. >> >> You're right that they only include the requirements for python 2. We >> try not to mark those packages as "universal" for that reason. >> >>> >>> This is broken - I've filed a bug about it (http://pad.lv/1431529). >>> >>> I think we should deprecate and remove the requirements-pyN files and >>> instead use environment markers directly in requirements.txt. That >>> will then flow into wheels and things should just work (plus we can >>> delete more pbr code). >>> >>> I haven't tested yet (and someone should) that it does all JUST WORK, >>> but thats easy: put an environment marker in a requirements.txt file >>> like so: >>> >>> argparse; python_version < '3' >> >> I think the last time this came up the feature wasn't available in pip >> yet, and so using separate files was the work-around. Are environment >> markers fully supported by pip/setuptools/whatever now? > > Donald says yes, at least for pip (which is all we need, since we > advise folk to use pip install -e . locally).
Not just advise - setup.py install is _explicitly_ not supported since it is broken by design and insecure. I've spoken with Donald about trying to figure out a way to determine if we're being run via straight setup.py install rather than via pip so that we can error descriptively... In any case: a) woot b) I agree, pip support is all we need >> If so, an option would be to have pbr recognize the version-specific >> input files as implying a particular rule, and adding that environment >> marker to the dependencies list automatically until we can migrate to a >> single requirements.txt (for which no rules would be implied). > > We could, or we could just migrate - I don't think its worth writing a > compat shim. Also agree. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
