I'm not sure what will be needed to get the PR accepted; At PyCon AU
Tennessee Leuwenberg started drafting a PEP for the expression of
dependencies on e.g. BLAS - its been given number 497, and is in the
packaging-peps repo; I'm working on updating it now.

On 13 August 2015 at 08:21, Nate Coraor <n...@bx.psu.edu> wrote:
> Hello all,
>
> I've implemented the wheel side of Nick's suggestion from very early in this
> thread to support a vendor-providable binary-compatibility.cfg.
>
>   https://bitbucket.org/pypa/wheel/pull-request/54/
>
> If this is acceptable, I'll add support for it to the pip side. What else
> should be implemented at this stage to get the PR accepted?
>
> Thanks,
> --nate
>
> On Tue, Jul 28, 2015 at 12:21 PM, Wes Turner <wes.tur...@gmail.com> wrote:
>>
>>
>> On Jul 28, 2015 10:02 AM, "Oscar Benjamin" <oscar.j.benja...@gmail.com>
>> wrote:
>> >
>> > On Fri, 24 Jul 2015 at 19:53 Chris Barker <chris.bar...@noaa.gov> wrote:
>> >>
>> >> On Tue, Jul 21, 2015 at 9:38 AM, Oscar Benjamin
>> >> <oscar.j.benja...@gmail.com> wrote:
>> >>>
>> >>>
>> >>> I think it would be great to just package these up as wheels and put
>> >>> them on PyPI.
>> >>
>> >>
>> >> that's the point -- there is no way with the current spec to specify a
>> >> wheel dependency as opposed to a package dependency. i.e this particular
>> >> binary numpy wheel depends on this other wheel, whereas the numpy source
>> >> pacakge does not have that dependency -- and, indeed, a wheel for one
>> >> platform may have different dependencies that\n other platforms.
>> >
>> >
>> > I thought it was possible to do this with wheels. It's already possible
>> > to have wheels or sdists whose dependencies vary by platform I thought.
>> >
>> > The BLAS dependency is different. In particular the sdist is compatible
>> > with more cases than a wheel would be so the built wheel would have a more
>> > precise requirement than the sdist. Is that not possible with
>> > pip/wheels/PyPI or is that a limitation of using setuptools to build the
>> > wheel?
>> >
>> >>>
>> >>> So numpy could depend on "blas" and there could be a few different
>> >>> distributions on PyPI that provide "blas" representing the different
>> >>> underlying libraries. If I want to install numpy with a particular one I 
>> >>> can
>> >>> just do:
>> >>>
>> >>>     pip install gotoblas  # Installs the BLAS library within Python
>> >>> dirs
>> >>>     pip install numpy
>> >>
>> >>
>> >> well,different implementations of BLAS are theoretically ABI
>> >> compatible, but as I understand it, it's not actually that simple, so this
>> >> is particularly challenging.
>> >>
>> >>
>> >> But if it were, this would be a particular trick, because then that
>> >> numpy wheel would depend on _some_ BLAS wheel, but there may be more than
>> >> one option -- how would you express that????
>> >
>> >
>> > I imagined having numpy Require "blas OR openblas". Then openblas
>> > package Provides "blas". Any other BLAS library also provides "blas". If 
>> > you
>> > do "pip install numpy" and "blas" is already provided then the numpy wheel
>> > installs fine. Otherwise it falls back to installing openblas.
>> >
>> > Potentially "blas" is not specific enough so the label could be
>> > "blas-gfortran" to express the ABI.
>>
>> BLAS may not be the best example, but should we expect such linked
>> interfaces to change over time? (And e.g. be versioned dependencies with
>> shim packages that have check functions)?
>>
>> ... How is an ABI constraint different from a package dependency?
>>
>> iiuc, ABI tags are thus combinatorial with package/wheel dependency
>> strings?
>>
>> Conda/pycosat solve this with "preprocessing selectors" :
>> http://conda.pydata.org/docs/building/meta-yaml.html#preprocessing-selectors
>> :
>>
>> ```
>> linux True if the platform is Linux
>> linux32 True if the platform is Linux and the Python architecture is
>> 32-bit
>> linux64 True if the platform is Linux and the Python architecture is
>> 64-bit
>> armv6 True if the platform is Linux and the Python architecture is armv6l
>> osx True if the platform is OS X
>> unix True if the platform is Unix (OS X or Linux)
>> win True if the platform is Windows
>> win32 True if the platform is Windows and the Python architecture is
>> 32-bit
>> win64 True if the platform is Windows and the Python architecture is
>> 64-bit
>> py The Python version as a two digit string (like '27'). See also the
>> CONDA_PY environment variable below.
>> py3k True if the Python major version is 3
>> py2k True if the Python major version is 2
>> py26 True if the Python version is 2.6
>> py27 True if the Python version is 2.7
>> py33 True if the Python version is 3.3
>> py34 True if the Python version is 3.4
>> np The NumPy version as a two digit string (like '17'). See also the
>> CONDA_NPY environment variable below.
>> Because the selector is any valid Python expression, complicated logic is
>> possible.
>> ```
>>
>> >
>> > --
>> > Oscar
>> >
>> > _______________________________________________
>> > Distutils-SIG maillist  -  Distutils-SIG@python.org
>> > https://mail.python.org/mailman/listinfo/distutils-sig
>> >
>>
>>
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG@python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Reply via email to