[Distutils] distlib and wheel metadata

[Nick Coghlan]

On 23 February 2017 at 23:04, Freddy Rietdijk <freddyrietdijk at fridh.nl>
wrote:

> > Here's an example I've just run into that involves a == dependency on
> a public package: I have a library that needs to access some C API
> calls on Windows, but not on other platforms. The natural way to do
> this is to split out the CFFI code into its own package,
> _mylib_windows_helper or whatever, that has zero public interface, and
> have mylib v1.2.3 require "_mylib_windows_helper==1.2.3; os_name ==
> 'nt'".
>
> You have a public library, that, depending on the platform, depends on a
> public (helper) library that has no public interface? That doesn't sound
> good to me. If you don't want to implement a public interface then it
> should just be included in the main library because it is in the end a
> requirement of the library. It's a pity you can't have a universal wheel
> but so be it. Choosing to depend on an exact version of a package that has
> no public interfance is in my opinion the wrong solution.
>
> As I stated before, though perhaps not explicitly, I cannot think of *any*
> good reason that one uses == in `install_requires`. Something like `>= 1.7,
> < 1.8` should be sufficient. In the CFFI case that should be sufficient
> unless you change your function signatures in a maintenance release (which
> is bad). And in case of a metapackage like PyObjC this should also be
> sufficient because it will downgrade dependencies when downgrading the
> metapackage while still giving you the latest maintenance releases of the
> dependencies.
>
> Regarding 'application', 'library', and 'metapackage'. In Nixpkgs we
> distinguish Python libraries and applications. Applications are available
> for 1 version of the interpreter, whereas libraries are available for all
> (supported) interpreter versions. It's nice if it were more explicit on say
> PyPI whether a package is a library or an application. There are difficult
> cases though, e.g., `ipython`. Is that an application or a library? As user
> I would argue that it is an application, however, it should be available
> for each version of the interpreter and that's why we branded it a library.
>

That sounds pretty similar to the distinction in Fedora as well, which has
been highlighted by the Python 3 migration effort: libraries emit both
Python 2 & 3 RPMs from their source RPM (and will for as long as Fedora and
the library both support Python 2), while applications just switch from
depending on Python 2 to depending on Python 3 instead.


> Metapackages. `jupyter` is a metapackage. We had to put it with the rest
> of the Python libraries for the same reason as we put `ipython` there. From
> a distributions' point of view I don't see why you would want to have
> them mentioned separately.
>

>From a distro point of view, explicit upstream metapackages would provide a
hint saying "these projects should be upgraded as a unit rather than
independently". We're free to ignore that hint if we want to, but doing so
means we get to keep the pieces if they break rather than just being able
to report the problem back upstream :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170223/aae0fb7d/attachment-0001.html>