[Distutils] distlib - installer support vs runtime support

[Vinay Sajip]

Paul Moore <p.f.moore <at> gmail.com> writes:

> Would it be worth considering splitting distlib into two separate
> parts - one that is intended solely for writers of installers and
> similar tools, and another for "runtime support" functions that end
> users would use? It may not be a practical thing to achieve, but it
> would be worth at least understanding the trade-offs involved.

While this could be done, it would not exactly be elegant, and IMO it would be
the wrong way to address the valid concerns you mention. It would make more
sense for pip to *contain* a specific version of distlib for its use (e.g. as a
.zip) so that it never worries about conflicts with another copy. This is the
approach that Django takes and it seems to work reasonably well for that
project.

Re. the size of distlib - it's larger than pip, because pip relies on a
external dependency (setuptools/distribute) to do a lot of its work, whereas
distlib is self-contained. So, direct size comparisons can be misleading (e.g.
distlib contains a _backport package for 2.6 support, which is not tiny;
distlib's tests contain tests for the backports plus a complete copy of
unittest2, again for 2.6 support).

The concerns about stability (in terms of API stability, as well as the
presence of bugs) are more valid than size. Given distlib's youth, we can
expect to see some API changes, as well as to see some bugs flushed out of the
woodwork. (Obviously, I would aim to keep API changes to a minimum.)

A good level of stability is generally achieved after a period of usage in
anger followed by feedback based on that usage. Until then, the test suite,
coverage results and docs will need to be used to give an indication of
quality.

Regards,

Vinay Sajip