[Distutils] PEP 376, the INSTALLER file, and system packages

Nick Coghlan ncoghlan at gmail.com
Fri Jan 22 22:52:57 EST 2016

On 23 January 2016 at 08:17, Nathaniel Smith <njs at pobox.com> wrote:
> On Fri, Jan 22, 2016 at 11:28 AM, Donald Stufft <donald at stufft.io> wrote:
>> Yea, that’s why I thought about dpkg (system) or system(Debian) or
>> something. The main reason I can think of for preferring “system” is if we
>> don’t want to change the valid characters for a value in this file. Then you
>> can have system(Debian) and system(Conda) and everything will work just
>> fine.
> Maybe to simplify the discussion we should just forget about INSTALLER,
> leave it in peace to be what the PEP says ("fyi this is the last program to
> touch this, in case anyone cares"), and add a new file with whatever
> syntax/semantics make sense. Filenames are cheap and plentiful, and no
> reason to complicate this discussion with hypothetical backcompat worries.

Right, that was my theory in implementing INSTALLER just as PEP 376
defined it - having pip write "pip" to that file is enough to let us

1. Controlled in a pip-compatible way
2. Controlled in a pip-incompatible way
3. pip compatibility not specified

Paul's right that at the time the assumption was each tool would just
write *its own* name into the file, but given the other changes that
have happened since then, it now makes sense that other tools that are
fully interoperable with another more-widely used installer may choose
to write that installer's name instead of their own, and the only
states we *really* care about from a UX perspective are "definitely
compatible", "definitely incompatible" and "don't know".

We may decide to do something more sophisticated later, but that would
be as part of someone finding the roundtuits to actually design a
plugin system for delegating to system package managers when running
as root.

>From a downstream perspective, the main thing we need to know in order
to choose a suitable value to put into that file is how pip decides to
use whatever we write there. For example, if pip were to emit a
warning message looking something like:

"<project> is not managed by pip, skipping (use '<INSTALLER content>'
or '--force' to update it)"

Then the distro could update our packaging policies such that we write
our respective package management command names into the INSTALLER
files when creating system packages.

(As far as the regex defining the permitted content goes,
appropriately caveating PEP 376 to better match the reality of how
current generation tools work is one of my main motivations for
revising the specification process)


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Distutils-SIG mailing list