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

[Ben Finney]

Chris Barker <chris.barker at noaa.gov> writes:

> On Tue, Apr 14, 2015 at 8:41 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
> > The point where I draw the line is supporting *dynamic* linking
> > between modules -
>
> I'm confused -- you don't want a system to be able to install ONE version
> of a lib that various python packages can all link to? That's really the
> key use-case for me....

Agreed. A key pain point for Python distributions is the lack of support
for installing *one* instrance of a Python library, and other Python
modules able to discover such installed libraries which meet their
declared dependency.

For example:

* Python distribution ‘foo’, for Python implementation “D” on
  architecture “X“, declares dependency on “bar >= 1.7”.

* Installing Python distribution ‘bar’ version 1.8, on a host running
  Python “D” for architecture “X”, goes to a single instance for the
  ‘bar’ library for that architecture and Python implementation.

* Invoking the ‘foo’ code on the same host will go looking
  (dynamically?) for the dependency ‘bar’ and find version 1.8 already
  installed in the one instance on that host. It uses that and all is
  well.

I'm in agreement with Chris that, while the above example may not
currently play out as described, that is a fault to be fixed by
improving Python's packaging and distribution tools so that it *is* a
first-class use case.

Nick, you seem to be arguing against that. Can you clarify?

-- 
 \      “Natural catastrophes are rare, but they come often enough. We |
  `\   need not force the hand of nature.” —Carl Sagan, _Cosmos_, 1980 |
_o__)                                                                  |
Ben Finney