Open Stack

On 03/16/2015 08:32 PM, Robert Collins wrote:
> On 17 March 2015 at 13:22, Doug Hellmann <doug at doughellmann.com> 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.