Re: [Python-Dev] External Package Maintenance (was Re: Please stopchanging wsgiref on the trunk)
At 11:23 AM 6/12/2006 -0700, Guido van Rossum wrote:
developers contributing code without wanting to give up control are the problem.
Control isn't the issue; it's ensuring that fixes don't get lost or reverted from either the external version or the stdlib version. Control is merely a means to that end. If we can accomplish that via some other means (e.g. an Externals/ subtree), I'm all for it. (Actually, perhaps Packages/ would be a better name, since the point is that they're packages that are maintained for separate distribution for older Python versions. They're really *not* "external" any more, they just get snapshotted for release.) I guess I should say, control isn't the issue for *me*. I can't speak for anyone else. Fredrik has raised the issue of API forks, but I haven't encountered this myself. I *have* seen some developers make spurious "cleanups" to working code that breaks compatibility with older Python versions, though, just not in wsgiref. But I don't mind policing such things myself as long as I have only one subtree to svn log (versus having to track three separate logs and diffs for Lib/wsgiref/, Lib/test/test_wsgiref.py, and Doc/lib/libwsgiref.tex, and then having to reformat the diffs to apply to a different directory layout). Now, Barry's approach to the email package makes good sense to me, and I'd use it, except that SVN externals can't sync individual files. I'd have to create Lib/wsgiref/tests (and make a dummy Lib/test/test_wsgiref that invokes them) and Lib/wsgiref/doc (and make Doc/lib/lib.tex include libwsgiref.tex from there). If those changes are acceptable, I'd be happy to take that as a compromise approach. I'll still have to manually update the Python PKG-INFO (due to no setup.py), but it'd be better than nothing.
On Mon, Jun 12, 2006 at 03:12:20PM -0400, Phillip J. Eby wrote:
encountered this myself. I *have* seen some developers make spurious "cleanups" to working code that breaks compatibility with older Python versions, though, just not in wsgiref.
Note that the standard library policy has always been that the library for Python 2.X does not need to work with an earlier Python interpreter. Modules that must continue to work with earlier versions are listed in PEP 291. (Yes, another PEP to look at in addition to 360. IMHO we should require all modules with version constraints or external master source to have comments indicating this *in the code*, at the top of every source file, so that someone writing a patch or bugfix knows what the requirements are.) --amk
On 6/12/06, A.M. Kuchling <amk@amk.ca> wrote:
IMHO we should require all modules with version constraints or external master source to have comments indicating this *in the code*, at the top of every source file, so that someone writing a patch or bugfix knows what the requirements are.
Agreed. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 12 Jun 2006 15:12:20 -0400 "Phillip J. Eby" <pje@telecommunity.com> wrote:
Now, Barry's approach to the email package makes good sense to me, and I'd use it, except that SVN externals can't sync individual files. I'd have to create Lib/wsgiref/tests (and make a dummy Lib/test/test_wsgiref that invokes them)
Which is email had to do.
and Lib/wsgiref/doc (and make Doc/lib/lib.tex include libwsgiref.tex from there).
See mimelib.tex in Python's docs -- I had to do the same thing. The PITA is that I have to build the docs in Python's svn and then copy them into the sandbox for the standalone distro. This isn't to bad when it's just one package, but if we adopt this approach more generally, we may want to establish some guidelines, which of course I'd be happy to stick to. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iQCVAwUBRI3L23EjvBPtnXfVAQLAEwP/dQNcTatFUz7saxzRw2SEDKfDYTIsd0On WdLkNbhr5E85upOg/12DQLmyHAKNbxO2OFZo6VuO7AdHF2OTgp8S6aAzAlOUq9eF y1fiQ0Qfto3xCx4y1RYI9caZTJPuIN/1n8IHHt9Gkx+IsV+VDl+dhE3tVUP7RqAY XxTRzc/sCys= =AJ/r -----END PGP SIGNATURE-----
Phillip J. Eby <pje@telecommunity.com> wrote:
Control isn't the issue; it's ensuring that fixes don't get lost or reverted from either the external version or the stdlib version. Control is merely a means to that end. If we can accomplish that via some other means (e.g. an Externals/ subtree), I'm all for it. (Actually, perhaps Packages/ would be a better name, since the point is that they're packages that are maintained for separate distribution for older Python versions. They're really *not* "external" any more, they just get snapshotted for release.)
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). Maintaining an external repository seems like a larger effort, and probably not worth it. Giovanni Bajo
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.
On 6/12/06, Phillip J. Eby <pje@telecommunity.com> 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
At 02:00 AM 6/13/2006 +0200, Giovanni Bajo wrote: 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
On 6/12/06, Phillip J. Eby <pje@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.
I'm not sure I understand. Is something like this the proposed directory structure (all within the python repo): python/trunk/ - current top-level where Lib, Modules, Python, Objects, etc live + Add another subdir under trunk/ called Externals/ + under Externals/ would be a directory per project (wsgiref, etree, etc) And each project could have it's own directory structure? This probably wouldn't be so bad. It would be particularly good if the subdirs under Externals/project could be similar (ie, they each have a Doc, Lib, src, etc. directories). The more consistency we have, the easier it is to remember and follow the rules. n
participants (7)
-
A.M. Kuchling -
Barry Warsaw -
Brett Cannon -
Giovanni Bajo -
Guido van Rossum -
Neal Norwitz -
Phillip J. Eby