<p dir="ltr">On Aug 12, 2015 16:49, "Robert Collins" <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
><br>
> I'm not sure what will be needed to get the PR accepted; At PyCon AU<br>
> Tennessee Leuwenberg started drafting a PEP for the expression of<br>
> dependencies on e.g. BLAS - its been given number 497, and is in the<br>
> packaging-peps repo; I'm working on updating it now.</p>
<p dir="ltr">I wanted to take a look at this PEP, but I can't seem to find it. PEP 497:<br>
  <a href="https://www.python.org/dev/peps/pep-0497/">https://www.python.org/dev/peps/pep-0497/</a><br>
appears to be something else entirely?</p>
<p dir="ltr">I'm a bit surprised to hear that such a PEP is needed. We (= numpy devs) have actively been making plans to ship a BLAS wheel on windows, and AFAICT this is totally doable now -- the blocker is windows toolchain issues, not pypa-related infrastructure.</p>
<p dir="ltr">Specifically the idea is to have a wheel that contains the shared library as a regular old data file, plus a stub python package that knows how to find this data file and how to make it accessible to the linker. So numpy/__init__.py would start by calling:</p>
<p dir="ltr">import pyopenblas1<br>
# on Linux modifies LD_LIBRARY_PATH,<br>
# on Windows uses ctypes to preload... whatever<br>
pyopenblas1.enable()</p>
<p dir="ltr">and then get on with things, or the build system might do:</p>
<p dir="ltr">import pyopenblas1<br>
pyopenblas1.get_header_directories()<br>
pyopenblas1.get_linker_directories()</p>
<p dir="ltr">This doesn't help if you want to declare dependencies on external, system managed libraries and have those be automatically somehow provided or checked for, but to me that sounds like an impossible boil-the-ocean project anyway, while the above is trivial and should just work.</p>
<p dir="ltr">-n</p>