[Distutils] Dynamic linking between Python modules (was: Beyond wheels 1.0: helping downstream, FHS and more)

[Chris Barker]

On Wed, May 20, 2015 at 3:46 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 21 May 2015 at 03:37, Chris Barker <chris.barker at noaa.gov> wrote:
> > As such, it _could_ play the role that pip+wheel (secondarily pypi) play
> in
> > the python ecosystem.
>
> In practice, it can't, as conda is entirely inappropriate as an input
> format for yum/apt/enstaller/zc.buildout/pypm/MSI/etc.


well, I'm making a strong distinction between a build system and a
dependency management / install system. conda is not any kind of
replacement for distutils / setuptools. (kind of how rpm doesn't replace
configure and make. at all.) I'm still confused as to why pip plays as big
a role in building as it seems to, but I guess I trust that there are
reasons. Maybe it's only wheel that conda duplicates.

But this is all irrelevent, because:

Rather than being strictly technical, the reasons for this are mostly
> political (and partially user experience related)


Exactly. setuptools+pip+wheel is, and should be, the "official" python
distribution system.

 When folks try anyway,
> it mainly serves to alienate people using (or working on) other
> integration platforms rather than achieving anything productive (hence
> my comment about the "one package manager to rule them all" attitude
> of some conda proponents,


well, sorry if I've contributed to that -- but I guess for my part, there
is a core frustration -- I have only so much time (not much), and I want to
support multiple communities, -- and I simply can't do that without doing
twice as much work. Duplication of effort may be inevitable, but it is
still frustrating.

That way, Python developers can focus on
> learning one publication toolchain (anchored by pip & PyPI), while
> users of integrated platforms can use the appropriate tools for their
> platform.
>

That's all very nice, and it works great for packages that don't have any
external dependencies, but if I'm trying to publish my python package,
pip+wheel simply doesn't support what I need -- I can't use only one
publication toolchain. And indeed, even if it did (with my vaporware better
support for shared libs), that would be incompatible with conda, which
does, in fact, support everything I need.

conda doesn't bridge that gap for Python in the general case, as it is
> itself an integrator tool managed independently of the PSF


well that is a political/social issue.


> and
> designed to consume components from *multiple* language ecosystems and
> make them available to end users in a common format.
>

not sure why that precludes it being used for python -- Python somehow HWAS
to use a system that is only designed for Python? why?


> Python's far too far down
> the distutils->setuptools->pip path to be readily amenable to
> alternatives


agreed. this is the key point - it's gotten a bit blended in with teh
technical issues, but that really is the key point. -- I'll shut up now :-)

(at least about this)

-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

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150521/539c271f/attachment-0001.html>