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

Brett Cannon brett at python.org
Tue Jun 13 02:27:47 CEST 2006


On 6/12/06, Phillip J. Eby <pje at telecommunity.com> wrote:
>
> At 02:00 AM 6/13/2006 +0200, Giovanni Bajo wrote:
> >IMO, the better way is exactly this you depicted: move the official
> >development
> >tree into this Externals/ dir *within* Python's repository. Off that, you
> can
> >have your own branch for experimental work, from which extract your own
> >releases, and merge changes back and forth much more simply (since if
> they
> >reside on the same repository, you can use svnmerge-like features to find
> out
> >modifications and whatnot).
>
> Yes, that's certainly what seems ideal for me as an external developer.  I
> don't know if it addresses the core developers' concerns, though, since it
> would mean having Python code that lives outside of the Lib/ subtree,
> tests
> that live under other places thatn Lib/test, and documentation source that
> lives outside of Doc/.  But if those aren't showstoppers then it seems
> like
> a winner to do it for 2.6.


As long as this is the exception and not the rule, I am fine with this
personally.  ctypes already has its tests in its package directory and no
one has complained yet (and I didn't find it a problem since the traceback
lists the file location of the failing test).

Not every contributed piece of code should go in there, though, if the
contributor has not shown a certain level of dedication to their personal
userbase and thus cover the inconvenience put on python-dev of having two
different places to check for everything.

And obviously the hope would be to eventually have something moved from
Extensions after a certain amount of time and merged into the rest of the
tree so that the dichotomy does not become a huge burden.

On the other hand, the example of ctypes of having tests kept in the package
directory instead of Lib/test might be a good thing overall, regardless of
whether the package is from the outside or not.  That would leave the
package location and docs as the only two places you would need to check for
chagnes and might help with organizing and promote smaller unit test files
for packages that spread their tests across multiple files.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060612/e305ab92/attachment.html 


More information about the Python-Dev mailing list