Re: [Distutils] Working toward Linux wheel support

On Fri, Aug 14, 2015 at 9:17 AM, Steve Dower <stev...@python.org> wrote:

> I actually like two ideas for Windows (not clear to me how well they apply> on other platforms),


I think this same approach should be used for OS-X, not sure about Linux --
on LInux, you normally have "normal" ways to get libs.

both of which have been mentioned in the past:
>> * PyPI packages that are *very* thin wrappers around a shared library>> For example, maybe "libpng" shows up on PyPI, and packages can then depend> on it. It takes some care on the part of the publisher to maintain> version-to-version compatibility (or maybe wheel/setup.py/.cfg grows a> way to define vendored dependencies?) but this should be possible today.>

excep that AFAICT, we have no way to describe wheel (or platform) dependent
dependencies:

i.e "this particular binary wheel, for Windows depends on the libPNG
version x.y wheel"

Though you could probably fairly easily path that dependency into the wheel
itself.

But ideally, we would have a semi-standard place to put such stuff, and
then the source package would depend on libPNG being there at build time,
too, but only on Windows. (or maybe only on OS-X, or both, but not Linux,
or...)

Or just go with conda :-) -- conda packages depend on other conda packages
-- not on other projects (I.e. not source, etc). And yuo can do platform
dependent configuration, like dependencies.

* "Packages" that contain shared sources
>> One big problem on Windows is there's no standard place to put library> sources, so build tools can't find them. If a package declared "build> requires libpng.x.y source" then there could be tarballs "somewhere" (or> even links to public version control) that have that version of the source,> and the build tools can add the path references to include it.>

That would be the source equivalent of the above, and yes, I like that idea
-- but again, you need a way to express platform-dependent dependencies.
Though given that setup.py is python code, that's not too hard.

There was discussion about an "incompatible_with" metadata item at one
> point. Could numpy include {incompatible_with: "scipy<x.y"} in such a> release? Or would that not be possible.>

circular dependency hell! scipy depends on numpy, not teh other way around
-- so it needs to be clear which version of numpy a given version of scipy
depends on.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chri...@noaa.gov