[Python-Dev] Status of packaging in 3.3

PJ Eby pje at telecommunity.com
Wed Jun 20 19:29:36 CEST 2012


On Wed, Jun 20, 2012 at 9:02 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On Wed, Jun 20, 2012 at 9:46 PM, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
> > Agreed, especially if the "proven in the wild" criterion is required
> > (people won't rush to another third-party distutils replacement, IMHO).
>
> The existence of setuptools means that "proven in the wild" is never
> going to fly - a whole lot of people use setuptools and easy_install
> happily, because they just don't care about the downsides it has in
> terms of loss of control of a system configuration.
>

Um, this may be a smidge off topic, but what "loss of control" are we
talking about here?  AFAIK, there isn't anything it does that you can't
override with command line options or the config file.  (In most cases,
standard distutils options or config files.)  Do you just mean that most
people use the defaults and don't care about there being other options?
And if that's the case, which other options are you referring to?

If the long-term goal is to draw setuptools users over to packaging, then
AFAIK the packaging effort is still missing a few things, like build-time
dependencies and alternatives to setuptools' entry points and "extras", as
well as the ability to integrate version control for building sdists
(without requiring the sdist's recipient to *also* have the version control
integration in order to build the package or recreate a new sdist).

These are just the missing features that I know of, from recent
distutils-sig discussions; I don't know how complete a list this is.  While
no single one of these features is directly used by every project or even a
majority of such projects, there is a correlation between size of a project
and the likelihood that they are depending on one or more of these
features.  i.e., the bigger and more widely-used the project, the more
likely it is to either use one of these features, or depend on a project
that does.

Some of these features could be built on top of packaging, in more or less
the same way setuptools is built on top of distutils.  But whether they're
done inside or outside of the packaging library, somebody's going to have
to do them, for people to be able to migrate off of setuptools.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120620/802dcf3e/attachment.html>


More information about the Python-Dev mailing list