[Python-Dev] External Package Maintenance (was Re: Please stop changing wsgiref on the trunk)

Barry Warsaw barry at python.org
Mon Jun 12 19:42:37 CEST 2006

Hash: SHA1

On Mon, 12 Jun 2006 13:08:52 -0400
"Phillip J. Eby" <pje at telecommunity.com> wrote:

> While I won't claim to speak for the other authors, I would guess
> that they have the same reason for wanting that status as I do: to be
> able to maintain an external release for their existing users with
> older versions of Python, until Python-in-the-field catches up with
> Python-in-development.

I handle this in a different way for the email package, which used to be
externally maintained and effectively still supports Pythons back to
2.1.  I'm happy (no, ecstatic) if others want to help maintain it
(w/discussion on email-sig of course), but I'll probably still be the
one doing standalone releases.

I do this by maintaining a directory in the sandbox that externals in
the correct url from the Python repo, and also provides all the
necessary distutils and documentation chrome used to support the
standalone releases. That way, the code lives in Python's primary repo,
but it's still easy enough for me to spin releases.

The catch of course is that I have three checkouts for each of the
three major versions of email.  Two of them pull from branches in the
Python repo while one (currently) pulls from the trunk.  Yes, it's a
PITA, but I could reduce the amount of work by deciding on a different
mix of version compatibility.

I don't know if that will work for the other PEP 360 packages, but it
works for me.

- -Barry
Version: GnuPG v1.4.2.2 (GNU/Linux)


More information about the Python-Dev mailing list