Re: [Distutils] Working toward Linux wheel support

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....@gmail.com> wrote:>>>>>> On Jul 28, 2015 10:02 AM, "Oscar Benjamin" <osca...@gmail.com>>> wrote:>> >>> > On Fri, 24 Jul 2015 at 19:53 Chris Barker <chri...@noaa.gov> wrote:>> >>>> >> On Tue, Jul 21, 2015 at 9:38 AM, Oscar Benjamin>> >> <osca...@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  -  Dist...@python.org>> > https://mail.python.org/mailman/listinfo/distutils-sig>> >>>>>>> _______________________________________________>> Distutils-SIG maillist  -  Dist...@python.org>> https://mail.python.org/mailman/listinfo/distutils-sig>>>>> _______________________________________________> Distutils-SIG maillist  -  Dist...@python.org> https://mail.python.org/mailman/listinfo/distutils-sig>



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