[Python-ideas] Where has packaging gone?

Nick Coghlan ncoghlan at gmail.com
Mon Jul 16 14:08:30 CEST 2012


(the list address on the original email I replied to was broken)

On Mon, Jul 16, 2012 at 6:55 PM, Michele Lacchia
<michelelacchia at gmail.com> wrote:
> Hi,
> I read this:
> http://www.gossamer-threads.com/lists/python/dev/992979
>
> but at the end nobody posted to it anymore. I would like to know what will
> now happen, since as far as I understood, the development of packaging
> has stopped and Bento (David Cournapeau library) has appeared.

No, the distutils2 project continues and is still being actively
developed. (distutils2 *is* packaging - the name on PyPI is just
different from the name that will be used when it is added to the
standard library). Bento is a project that aims to tackle part of
distutils that distutils2 hasn't really looked at yet: creating a more
flexible build system (or, more accurately, making it easier to hook
into *existing* build systems rather than defining yet another one).

(In fact, the lack of attention to the build system flaws is one of
the big reasons distutils2/packaging was deemed unready for stdlib
inclusion in 3.3)

> So what will happen now? Packaging will continue the development? Or
> will be Bento replace it? Personally I don't care which tool will become
> standard,
> but I do feel the need for a standard to be created.

The point of having documented standards in PEP form is that there can
(and will) be multiple projects that produce and consume those
standard formats.

> - PEP 345 (http://www.python.org/dev/peps/pep-0345/)
> - PEP 376 (http://www.python.org/dev/peps/pep-0376/)
> - PEP 386 (http://www.python.org/dev/peps/pep-0386/)

Those PEPs are *already* standards and are actively supported by
external projects today. One key missing piece is standard library
support, which the packaging module is intended to provide. However,
it was deemed that the project was not quite mature enough for 3.3,
thus it will continue to be developed (with a faster iteration cycle)
as distutils2, with a view to including a more mature version of the
API for 3.4. This will likely take the form of additional PEPs that
more clearly define what is to be added and *why* it is being added,
with one focus being making it easier to build additional tools that
produce and consume metadata in the standard formats, rather then
being a comparatively unwieldy monolithic system like the original
distutils.

Cheers,
Nick.

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


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



More information about the Python-ideas mailing list