[Python-Dev] standard libraries don't behave like standard 'libraries'

[Yuval Greenfield]

On Fri, Nov 13, 2009 at 9:35 AM, Kevin Teague <kevin at bud.ca> wrote:
>
> It's also worth noting that there are three issues with respect to standard
> library packaging which are all orthologous:
>
>  * Packaging for metadata: The standard library could be packaged so that
> there is consistent metadata about the distributions which compromise the
> standard library (version, author, maintainer, etc). This could be useful so
> that it would be easier to see at a glance which packages changed between
> any two Python releases. For example, I have a script which compares two
> working sets of packages and generates a web page with a colour-coded list
> of differences between those two working sets, based on the size of the
> version number bump, e.g. major.medium.minor (doesn't work with packages
> which use odd version numbering schemes). I've used this to compare working
> sets between different Grok releases or Plone releases to help see where the
> activity or major API changes might be happening inside any given Zope-based
> release. However, this script only works on 80% of the code, the other 20%
> is in the standard library, which is currently a black-box.
>
>    Also, if PEP 376 is accepted, then the standard library will be
> inviolation of the stanard metadata for installed packages unless this
> happens.
>
>  * Packaging for release:  The standard library could be packaged so that
> releases happen on PyPI. This could be useful so that it's easier to consume
> newer versions of a package before those packages are included in the next
> Python release. It could also make Python upgrades easier, as you could
> hold-back packages which might otherwise break an application upon upgrade.
> I happened to find a bug in a standard library package today, and currently
> my option is to: Submit bug report to PyPI, wait for Python 2.7 release,
> then wait for Plone to update to Python 2.7. I'm looking at many years
> before this fix goes into my production application, so in the meantime I
> need to maintain a work-around for the bug as well account for the day when
> this bug is fixed. It makes a mess of the code. If it was possible to
> release this package on PyPI, this could reasonably happen in a few days or
> at worst a couple months. The setup.py for that package could be updated to
> require the newer version of the package, and the workaround could be
> removed from the code.
>
>  * Packaging for resizing: The standard library could be packaged so that it
> could be made smaller or larger, or there could be different sized standard
> libraries made with different Python releases.
>
> So there are benefits to packaging the standard library which would be
> useful, for reasons which would have no impact on the "batteries included"
> aspect of Python.
>
> Plus, if the standard library was packaged and releases were made on PyPI
> (in addition to including them normally in the Python releases), we *might*
> be able to use PyPI's commenting infrastructure on this packages (~evil
> grin~).
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ubershmekel%40gmail.com
>

I kinda like the idea that the only packages included in the python
trunk would be distribute and pip (maybe just svn:external). Upon
packaging python for distribution (by installer or by source) the
relevant batteries would be included. Moving packages in and out of
the standard library just becomes so standard.

But of course this really should be decided by the people who work
most with the trunk and as I understand
http://mail.python.org/pipermail/stdlib-sig/2009-September/000609.html
this discussion's already run its course.

--yuv