Mailman 3 September 2005 - Distutils-SIG

#egg links off a find-links page
by Ben Bangert 21 Sep '05

21 Sep '05

I'm trying to make a bunch of subversion directories available on a page for use with find-links to provide one place for it to fetch all the packages I require. Here's the page where I put them all: http://pylons.groovie.org/ Running the ez_setup script like this: python ez_setup.py -f http://pylons.groovie.org/ Pylons It properly gets the Pylons trunk, checks the version, etc. Then it searches for dependencies, and searches PyPI for PasteDeploy even though I listed it with #egg=PasteDeploy on the page. Of course it doesn't find the one I specifically wanted in PyPI (a dev version), so it then fails rather than noticing the egg link. Any ideas? Thanks, Ben

2 1

setuptools docs: Declaring Dependencies
by Ian Bicking 21 Sep '05

21 Sep '05

I'm reading through the documentation some... Regarding this: > Note, by the way, that if you declare your dependencies in setup.py, > you do not need to use the require() function in your scripts or > modules, as long as you either install the project or use setup.py > develop to do development work on it. (See "Development Mode" below > for more details on using setup.py develop.) I don't think this is quite true. In particular, I've noticed if you install a package A --multi-version, it fulfills the requirement for A. And if you have a package B that requires A, when you require('B') then A will be loaded (added to sys.path, more technically). But if B is *not* installed --multi-version you can start using it without require()ing it, and A won't have been loaded. Given this, I feel like I need to do the basic require()s in my __init__.py. But, at least for some packages (like SQLObject) I want the package to be usable without setuptools. It gets complicated then, because you'd have to do: try: import pkg_resources try: pkg_resources.require(...) except pkg_resources.ResolutionError: # Who knows how everything may be installed, lets be # optimistic and wait for a later ImportError... pass except ImportError: pass At least, that's the best I've figured out.

2 2

Getting tired with py2exe
by Thomas Heller 21 Sep '05

21 Sep '05

I'm slowly getting tired maintaining py2exe. It is far from perfect, although it has interesting features (I would say). The problem, apart from the work, is that it is good enough for me - I can do everything that I need with it. But I assume I use far less libaries than other Python programmers, so a lot of bugs will never bite me. It is also interesting that the recently introduced bundle-files option, which allows to build single-file exes has gained a lot of interest - although the ONLY use case (so far) I have myself for it is to implement inproc COM servers which will compatible with Python clients (and other Python inproc COM servers) because of the total isolation of the Python VMs. Is anyone interested in taking over the maintainance, documentation, and further development? Should py2exe be integrated into another, larger, package? Pywin32 comes to mind, but also Philip Eby's setuptools (that's why I post to distutils-sig as well)... Thomas

6 6

setuptools: site_dirs
by Ian Bicking 20 Sep '05

20 Sep '05

With easy_install I can specify --site-dirs to make it setup package with .pth files. But with setuptools alone I can't, particularly "python setup.py develop". I'm not sure if there's a setting in distutils.cfg I could use...? There doesn't seem to be any appropriate command-line option. I'm also not sure how the site directories are identified...? In this case, on Debian, /usr/local/lib/pythonX.Y/site-packages isn't recognized as such a directory, even after I added it with site.addsitedir in sitecustomize. Ian

2 3

setuptools: name quoting
by Ian Bicking 20 Sep '05

20 Sep '05

I'm a bit confused about name quoting. I have a package with a name "Todo_SQLObject_ZPT", and egg_info writes to "Todo-SQLObject-ZPT.egg-info". Why? I thought -'s were bad, but _'s were okay...? I'm also getting a traceback when I try to do "python setup develop", following. The application that is causing this problem is at http://svn.pythonpaste.org/Paste/apps/Todo_SQLObject_ZPT/trunk (it's probably broken in other ways, I'm still in the process of converting it). I'm using the latest CVS version of setuptools. Todo_SQLObject_ZPT$ python setup.py egg_info develop running egg_info writing ./Todo-SQLObject-ZPT.egg-info/PKG-INFO writing top-level names to ./Todo-SQLObject-ZPT.egg-info/top_level.txt running develop Traceback (most recent call last): File "setup.py", line 18, in ? package_data={ File "/usr/local/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/local/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/usr/local/lib/python2.4/distutils/dist.py", line 965, in run_command cmd_obj.ensure_finalized() File "/usr/local/lib/python2.4/distutils/cmd.py", line 117, in ensure_finalized self.finalize_options() File "/usr/home/ianb/co/setuptools/setuptools/command/develop.py", line 45, in finalize_options easy_install.finalize_options(self) File "/usr/home/ianb/co/setuptools/setuptools/command/easy_install.py", line 181, in finalize_options self.package_index = self.create_index( File "/usr/home/ianb/co/setuptools/setuptools/package_index.py", line 128, in __init__ Environment.__init__(self,*args,**kw) File "/usr/home/ianb/co/setuptools/pkg_resources.py", line 558, in __init__ self.scan(search_path) File "/usr/home/ianb/co/setuptools/pkg_resources.py", line 588, in scan self.add(dist) File "/usr/home/ianb/co/setuptools/pkg_resources.py", line 610, in add if dist not in dists: File "/usr/home/ianb/co/setuptools/pkg_resources.py", line 1760, in __cmp__ def __cmp__(self, other): return cmp(self.hashcmp, other) File "/usr/home/ianb/co/setuptools/pkg_resources.py", line 1760, in __cmp__ def __cmp__(self, other): return cmp(self.hashcmp, other) File "/usr/home/ianb/co/setuptools/pkg_resources.py", line 1755, in <lambda> lambda self: ( File "/usr/home/ianb/co/setuptools/pkg_resources.py", line 1782, in parsed_version self._parsed_version = pv = parse_version(self.version) File "/usr/home/ianb/co/setuptools/pkg_resources.py", line 1797, in version raise ValueError( ValueError: ("Missing 'Version:' header and/or PKG-INFO file", Todo-SQLObject-ZPT [unknown version] (/usr/home/ianb/co/Todo_SQLObject_ZPT))

3 4

setuptools package_data behavior
by Greg Steffensen 20 Sep '05

20 Sep '05

Hey, I'm trying to use setuptools (which looks extremely cool) to distribute a reasonably simple python package (clipartbrowser on pypi, if anyone's curious), and am running into difficulty figuring out how to include some data files. My package is more or less laid out as follows (based on the example layout provided in Ian's setuptools presentation): clipartbrowser/ README COPYING ez_setup.py setup.py clipartbrowser/ __init__.py browser.py clipartbrowser.glade repositories/ __init__.py localocal.py localocal.glade I already have the code setup to use pkg_resources to access the data files (clipartbrowser.glade and localocal.glade), and have tried to list them under package_data in setup.py several ways (including "package_data = {'' : '['*.glade']} " ), but they never seem to be included in the tarball when I use "setup.py sdist". They are included when I do "setup.py bdist_egg", but for now I'd rather distribute using traditional tarballs. Am I doing something wrong? Also, the README is magically included in the sdist tarball no matter what I do, but I'd like to include COPYING, AUTHORS, etc. Is there a "correct" way to do this? Thanks, Greg

2 2

Re: [Distutils] Installed but can't run the quickstart
by Ian Bicking 19 Sep '05

19 Sep '05

Bob Ippolito wrote: > Well, if it makes a difference, EasyInstall works great on Mac OS X and > Windows. If Debian users had been more active with the EasyInstall > development process then the experience would be better there also. I've used EasyInstall on Debian all along, without problems (well, no more than anyone else I think). I guess I just happened to avoid conflicts with debian packages (well, sometimes). The setuptools deb package should just be removed; as far as I can tell nothing depends on it anyway (well, at least on my now-Ubuntu system "apt-cache rdepends python2.3-setuptools" shows nothing). There is a significant concern about setuptools conflicting with Debian packages, which I have encountered, and you can't always uninstall the Debian package because that can have cascading effects. At some point there needs to be a way to tell setuptools that a package has been provided, egg or no egg. Surprisingly nothing depends on ElementTree (that I can find), but docutils is caught up in the network of Debian dependencies. (Well, there's also ways of indicating to Debian that you've provided a dependency somehow besides the package, but I can't remember how.) Since this really has just become a Distutils discussion I'll copy it over there... -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

1 0

Files under /etc and /usr/share
by Vincenzo Di Massa 18 Sep '05

18 Sep '05

Hi, It is some weeks I put easy-deb on http://easy-deb.sf.net. I'm now considering improvements to make a new release. I have two things in mind: 1) make easy-deb a setup command (now it is an external tool) 2) provide a way to put files into /etc About point 2): Is it possible to install things into /etc using setuptools/easy_install? I think that this feature will be very appreciated. I know setup.py philosopy is to put everything inside eggs, but config files are a really special case! It would be nice beeing able to tell in setup.py what the config files/dirs are. The generated egg should install the config files on user request (using a gen_config script) or just when the neded are not config files on the system. Another idea is for heavy data. Consider for example moin_moin. Using easy-deb i managed to aotomatically pacakge it into an egg (which is contained into a deb-package). The problem here is that it installs the template files inside the egg. Since template files must be copied "somewere" it is bat to put them into the egg where they are hidden/zipped. Moreover it would be nice to make the eggs inside /usr/lib/python?.?/site-packages more lightweight removing package data from them. There are 2 kind of package data: data that is used *by* the module code and data that is used *with* the module. moinmoin is just an example of module whose data is not used by the code but with the code. I have no idea how this could be done, but it would be good (IMHO). Another nice thing to have in setuptools is a --nodeps option. Packagers really need to install an egg (into a package of course) even if its dependencies are not on the system. Skipped dependencies could be reported inside a skipped_deps.txt file or on stdout (so that packagers can add the dependency info to the generated packages). Ciao Vincenzo ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.messenger.yahoo.com

3 4

Re: [Distutils] Broken setuptools again?
by Phillip J. Eby 18 Sep '05

18 Sep '05

At 11:05 AM 9/18/2005 -0700, Ben Bangert wrote: >For example, in the 0.6a2 upgrade, it seems the easy_install script >wasn't updated or something. So now easy_install.pth was updated to >refer to the new setuptools version, but easy_install.py itself was >not. This results in this message: > >infopkg_resources.VersionConflict: (setuptools 0.6a2 (/Library/ >Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/ >setuptools-0.6a2-py2.4.egg), Requirement.parse('setuptools==0.6a1')) > >The first line of traceback is more revealing: >Traceback (most recent call last): File "/usr/local/bin/ >easy_install.py", line 4, in ? pkg_resources.run_script >('setuptools==0.6a1', 'easy_install.py') > >Sure enough, the script wasn't updated during the setuptools 0.6a1 -> >0.6a2 upgrade. As such, easy_install is currently broken on my system >and completely unusable. That's because 'easy_install.py' is no longer the script that runs EasyInstall. It's 'easy_install' now, with no extension, as described in the current documentation. This is probably not as clear as it should have been; this was based on a very new feature, and honestly I forgot about the upgrade scenario, and the fact that existing EasyInstall users would be accustomed to running easy_install.py instead. (Especially since on Windows, an easy_install.py is still generated alongside the new easy_install.exe file.) I'll release 0.6a3 with an easy_install.py script that tells you to run 'easy_install' instead. (I did think of the "python -m easy_install" case, and if you run that it'll tell you to run it the new way.) >As I'm working on several Python programs, I've been pondering using >setuptools for their distro as I want the functionality it has but >I'm not ready to be sending users to something that breaks so often >(at least in my moderate usage attempts). When do you expect a >"Stable" release? Any ideas how I can fix my problem so I can use >setuptools again? Current versions of setuptools are maintained on the cheeseshop servers more or less indefinitely, so you should be able to just freeze what version of ez_setup.py you use by including it directly in your package. Unfortunately, the cheeseshop changed its download locations recently, and broke backward compatibility with existing copies of ez_setup. Hopefully this won't happen again, although I have no control over it. As for a stable release, all I can say is that setuptools' API stability is now pretty good, and I don't expect any significant changes. Hopefully, everything from here on out should be new features, and hopefully they will be add-ons rather than things needing to be grafted into the basic structure. Setuptools tends to use its own new features first, however, and the problem you experienced with 0.6a2 is an example. I don't take this to mean that 0.6a2 is broken, however. If you were installing 0.6a2 fresh, you wouldn't have had the problem that you did. It's less of a problem with stability per se, than with having robust upgrades. In the long run, we should have a package management tool that can deal with things like removing outdated scripts, but we don't have one now. If by "stable" you mean that setuptools doesn't have any bugs, then at this point the most "stable" releases are 0.5a13, 0.6a1, and 0.6a2. They do what they do, although each version has features that the earlier ones don't. 0.5a13 in particular has a wealth of limitations compared to the 0.6 releases, and the main reason there were so many releases in the 0.5 line is that it *was* unstable. There was quite a bit of reorganization of the installation process happening there. Because of the many problems with 0.5, the 0.6a1 release was developed in CVS without making interim releases to PyPI or updating the svn:externals ez_setup, precisely to avoid having these kinds of problems. So, I guess what I'm saying is that you have a couple of options regarding how you want to embed setuptools. You can use svn:externals, in which case you'll be getting only releases judged to be of moderately stable quality. There were several points between 0.5a13 and 0.6a1 (such as the two 0.6a1 candidate releases) that I did *not* update the svn:externals ez_setup, so that folks like yourself wouldn't end up accidentally participating in the testing. :) However, if you want to personally vet the versions you use with your package, you should be able to just keep a personal copy of ez_setup.py, and even modify it for your own use. Heck, you don't even have to modify it or keep such a version, because the 'use_setuptools()' function takes a version and a download base URL. You can save a copy of the setuptools eggs you want to use, and simply set the version and download base in your setup script. So, you don't have to depend on anybody else to keep the version you want available. So, to put a different spin on your question... you can determine what *you* consider to be a stable release of setuptools, and make your system use that. :) (It's true that if someone already has a newer version of setuptools, that's what will be used instead. However, that's *their* responsibility, and they can and should bitch to me if something breaks.)

1 0

setuptools 0.6a2 released
by Phillip J. Eby 17 Sep '05

17 Sep '05

It generates console scripts and .exe wrappers. I decided not to implement find_package_data(), because it turned out to be a lot more complex than I thought it would be. In fact, it was complex enough that I was wondering if I might need to rewrite the entire distutils in order to make it work well. :( Anyway, 0.6a2 is out, so enjoy. I'd be interested in hearing feedback on how the GUI wrappers should be done. I've already figured out how to compile a launcher variant that doesn't create a console window on Windows, so that part's easy. I guess we can always add fancy features for Mac et al later. One thing I'm not too sure about for GUIs on non-Windows platforms is the whole detach or not-to-detach thing. On Windows, I was planning to make GUIs run detached from the current console, but I'm not sure if that's the "normal" thing to do on other platforms.

1 0