Bazaar support for setuptools
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well, I hacked this together pretty quickly but it seems to work for my particular use case. The Mailman source code is now kept under the Bazaar revision control system, and I'm about to merge a branch that converts the Mailman 3 branch from autoconf-based builds to setuptools. So I needed Bazaar support in order to build my sdist files and such. Writing the plugin code was pretty easy after Michael Hudson gave me the key bzrlib clues. Maybe this could be included by default in the next version of setuptools? I've added it as an attachment to SF patch #1757782 https://sourceforge.net/tracker/index.php? func=detail&aid=1757782&group_id=5470&atid=305470 Side note: I found it interesting and a bit annoying that setuptools doesn't call find_files_for_bzr() recursively. It would seem like the framework should do the recursion instead of the plugin, as I'd think it would be the most common use case. In any event, the setuptools documentation should probably be clear that it's up to the plugin to recurse into subdirectories. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRqEb03EjvBPtnXfVAQLqAAP+PHgTq5B8pJR20DrbaLr3xx+vZAUJN2TK o4s9+5dPKrsm7YCoMkGla2xongmZcFqy9KlMuNJ3FT/5JgeneC4Og/52L+/A0HU0 4nFgBaXd1tKLQRVFKxr6CzqLqt9jnNfzXmNNNqweYvoa/wXU44WxL0sdiLxjljKT 1yzjcd3D1aA= =9uBA -----END PGP SIGNATURE-----
At 04:32 PM 7/20/2007 -0400, Barry Warsaw wrote:
Well, I hacked this together pretty quickly but it seems to work for my particular use case. The Mailman source code is now kept under the Bazaar revision control system, and I'm about to merge a branch that converts the Mailman 3 branch from autoconf-based builds to setuptools. So I needed Bazaar support in order to build my sdist files and such.
Writing the plugin code was pretty easy after Michael Hudson gave me the key bzrlib clues. Maybe this could be included by default in the next version of setuptools?
No, since it relies on a package (bzrlib) that's not in the stdlib or bundled with setuptools. You can, however, just add a setup.py to your module that declares the entry point, and upload the whole thing to Cheeseshop. You can even declare its dependency on bzrlib and have that automatically installed too, assuming that it's either on the Cheeseshop or you can supply a download link or page with download links in your setup(find_links=[...]).
Side note: I found it interesting and a bit annoying that setuptools doesn't call find_files_for_bzr() recursively. It would seem like the framework should do the recursion instead of the plugin, as I'd think it would be the most common use case.
Well, the assumption is that only the plugin knows whether a directory is a candidate for recursion. Also, some revision control systems only keep path information in one place, so trying to call the plugin recursively would be redundant.
In any event, the setuptools documentation should probably be clear that it's up to the plugin to recurse into subdirectories.
Fair enough; patches welcome. In fact, feel free to just go ahead and check documentation additions right in, just drop me a line and let me know what you did so I can double-check and edit if necessary.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Phillip, thanks for the quick response. On Jul 20, 2007, at 5:18 PM, Phillip J. Eby wrote:
At 04:32 PM 7/20/2007 -0400, Barry Warsaw wrote:
Well, I hacked this together pretty quickly but it seems to work for my particular use case. The Mailman source code is now kept under the Bazaar revision control system, and I'm about to merge a branch that converts the Mailman 3 branch from autoconf-based builds to setuptools. So I needed Bazaar support in order to build my sdist files and such.
Writing the plugin code was pretty easy after Michael Hudson gave me the key bzrlib clues. Maybe this could be included by default in the next version of setuptools?
No, since it relies on a package (bzrlib) that's not in the stdlib or bundled with setuptools.
Would it help if the plugin could fall back to the command line bzr (1) program if bzrlib wasn't installed in your Python? I've modified the code to do this and it seems to work fine either way. I haven't looked, but ISTM that both CVS and Subversion support have to work somewhat similarly. How does setuptools handle things if either cvs (1) or svn(1) weren't available?
You can, however, just add a setup.py to your module that declares the entry point, and upload the whole thing to Cheeseshop.
I could if the Cheeseshop was up right now. ;) Great idea. The code lives here: https://code.launchpad.net/~barry/setuptoolsbzr/trunk and I'll upload it to the Cheeseshop as soon as that service gets repaired.
You can even declare its dependency on bzrlib and have that automatically installed too, assuming that it's either on the Cheeseshop or you can supply a download link or page with download links in your setup(find_links=[...]).
I don't quite understand this last bit. Is there documentation on the find_links keyword argument? I couldn't find it. What I did find was dependency_links so I added the following to my setup.py: entry_points = { 'setuptools.file_finders': [ 'bzr = setuptoolsbzr:find_files_for_bzr', ], }, # Optionally grab bzr, which provides bzrlib extras_require = { 'bzrlib': ['bzr'], }, dependency_links = [ 'http://bazaar-vcs.org', ] I haven't actually tested this part because I can't find documentation on instructing 'python setup.py install' to install optional packages (is that even possible from the command line?). Note further that while bzrlib itself isn't a Cheeseshop package, there's a bzr tarball on that site that should -- I think -- install bzrlib as part of its setup.py.
Side note: I found it interesting and a bit annoying that setuptools doesn't call find_files_for_bzr() recursively. It would seem like the framework should do the recursion instead of the plugin, as I'd think it would be the most common use case.
Well, the assumption is that only the plugin knows whether a directory is a candidate for recursion. Also, some revision control systems only keep path information in one place, so trying to call the plugin recursively would be redundant.
Make sense, thanks.
In any event, the setuptools documentation should probably be clear that it's up to the plugin to recurse into subdirectories.
Fair enough; patches welcome. In fact, feel free to just go ahead and check documentation additions right in, just drop me a line and let me know what you did so I can double-check and edit if necessary.
The code's in the sandbox, right? I may indeed do that. Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRqFF6nEjvBPtnXfVAQJvhwP/T0rXxGARQDrQ2OdVcu3/3IMNY+MCUDj3 B8hYflHST/XgxVBnQGtlhROsKsMxvsqqVePuGlj9F0ykViaTu5dMcZ6XFdHw47QJ wZ7S++nQ1lN/DsRN1UJsIXpnrNkLkxaAloiTU8omkS7xJ0MVVRSkespt8iyBWaiz AZ7aCkWWO6M= =LswG -----END PGP SIGNATURE-----
At 07:31 PM 7/20/2007 -0400, Barry Warsaw wrote:
Would it help if the plugin could fall back to the command line bzr (1) program if bzrlib wasn't installed in your Python? I've modified the code to do this and it seems to work fine either way. I haven't looked, but ISTM that both CVS and Subversion support have to work somewhat similarly. How does setuptools handle things if either cvs (1) or svn(1) weren't available?
It doesn't use them; it just reads CVS/Entries and .svn/entries.
You can even declare its dependency on bzrlib and have that automatically installed too, assuming that it's either on the Cheeseshop or you can supply a download link or page with download links in your setup(find_links=[...]).
I don't quite understand this last bit. Is there documentation on the find_links keyword argument? I couldn't find it. What I did find was dependency_links so I added the following to my setup.py:
Eep, I meant dependency_links.
I haven't actually tested this part because I can't find documentation on instructing 'python setup.py install' to install optional packages (is that even possible from the command line?).
Try 'install_requires' instead of 'extras_require'.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 20, 2007, at 8:15 PM, Phillip J. Eby wrote:
At 07:31 PM 7/20/2007 -0400, Barry Warsaw wrote:
Would it help if the plugin could fall back to the command line bzr (1) program if bzrlib wasn't installed in your Python? I've modified the code to do this and it seems to work fine either way. I haven't looked, but ISTM that both CVS and Subversion support have to work somewhat similarly. How does setuptools handle things if either cvs (1) or svn(1) weren't available?
It doesn't use them; it just reads CVS/Entries and .svn/entries.
Ah, clever!
You can even declare its dependency on bzrlib and have that automatically installed too, assuming that it's either on the Cheeseshop or you can supply a download link or page with download links in your setup(find_links=[...]).
I don't quite understand this last bit. Is there documentation on the find_links keyword argument? I couldn't find it. What I did find was dependency_links so I added the following to my setup.py:
Eep, I meant dependency_links.
Turns out not to be necessary. Now that the cheeseshop is back up, I was able to check and find out that bzr is in there. It doesn't exactly help though because the tarball is broken. There's an open bug on this: https://bugs.launchpad.net/launchpad/+bug/125521/+index
I haven't actually tested this part because I can't find documentation on instructing 'python setup.py install' to install optional packages (is that even possible from the command line?).
Try 'install_requires' instead of 'extras_require'.
Great for testing, thanks. But um, how /do/ normal users tell setup.py to install those extra packages? Again, thanks Phillip. Now that the Cheeseshop is back up, you can grab the package from here: http://cheeseshop.python.org/pypi/setuptoolsbzr Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRqF8bXEjvBPtnXfVAQKxEgP/a3xzia9QIljMzCYa5WTvt6mduOPAvigm iFkMNltxPsP08v6WmoGoFPuYfZOuDve89lw1hpW7JXk4Be7xpgUOC+2yG9rkJTp6 brWmoeH7o/AunfyrgqAkbc2zpIq/GUXDtF+Lx5/jXfClXvliBaR9G2X+chSjSlF1 8pT+D/Liv0w= =CUOD -----END PGP SIGNATURE-----
At 11:24 PM 7/20/2007 -0400, Barry Warsaw wrote:
Great for testing, thanks. But um, how /do/ normal users tell setup.py to install those extra packages?
Normally, people use install_requires, and the packages get installed automatically if you're using setuptools or easy_install. Meanwhile, if you want to install a package's extras, you just use "easy_install foo[bar,baz]" to install package foo with extras bar and baz. "setup.py install" can't and won't ever handle extras. Please keep in mind, though, that extras are for *optional* features. Your package won't work without bzrlib, so that's not really an "extra" and probably shouldn't be defined as such.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [removed the bazaar list from the recipients] On Jul 21, 2007, at 1:02 AM, Phillip J. Eby wrote:
At 11:24 PM 7/20/2007 -0400, Barry Warsaw wrote:
Great for testing, thanks. But um, how /do/ normal users tell setup.py to install those extra packages?
Normally, people use install_requires, and the packages get installed automatically if you're using setuptools or easy_install.
Meanwhile, if you want to install a package's extras, you just use "easy_install foo[bar,baz]" to install package foo with extras bar and baz. "setup.py install" can't and won't ever handle extras.
Please keep in mind, though, that extras are for *optional* features. Your package won't work without bzrlib, so that's not really an "extra" and probably shouldn't be defined as such.
Agreed that in this particular example, extras aren't appropriate. But I have another use case where I definitely want to declare an optional dependency (e.g. munepy's optional dependence on the nose package for tests). So I'm wondering, why do you say setup.py can't and won't every support this? Is there a technical or philosophical limitation? I would think there should be a user friendlier way for a developer sitting there at the setup.py file to request that the optional packages get installed. I don't count using a different command as "user friendlier". Cheers, - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRqIbq3EjvBPtnXfVAQKKBwP+NIOV6bW6Pj55E2X76h3OYs1NT+OSP/ej pP8n6Vwmaq35fAfuwonYdQ6NErnf5SQqIrXLLmR8EgVQwoiGrzt4w/cd2AXEtn6I mZE87+P6wd4a96ts7ypUoh7keRdm8u/uX0knb2WBaZzT8AV67/kGknL08MlMWlRM NxXqn7qu9Mw= =r6Xh -----END PGP SIGNATURE-----
participants (2)
-
Barry Warsaw -
Phillip J. Eby