[Python-Dev] Status of packaging in 3.3 (original) (raw)

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 easyinstall 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