Mailman 3 September 2006 - Distutils-SIG

AttributeError: 'NoneType' object has no attribute 'group' in get_svn_revision
by Markus Tacker 18 Sep '06

18 Sep '06

Hoi, while trying to build the webadmin plugin for trac setuptools die with this error: # python setup.py install running install running bdist_egg Traceback (most recent call last): File "setup.py", line 34, in ? entry_points = { File "/usr/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/usr/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/usr/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/usr/lib/python2.4/site-packages/setuptools-0.6c2-py2.4.egg/setuptools/command/install.py", line 76, in run self.do_egg_install() File "/usr/lib/python2.4/site-packages/setuptools-0.6c2-py2.4.egg/setuptools/command/install.py", line 92, in do_egg_install self.run_command('bdist_egg') File "/usr/lib/python2.4/distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/usr/lib/python2.4/distutils/dist.py", line 965, in run_command cmd_obj.ensure_finalized() File "/usr/lib/python2.4/distutils/cmd.py", line 117, in ensure_finalized self.finalize_options() File "/usr/lib/python2.4/site-packages/setuptools-0.6c2-py2.4.egg/setuptools/command/bdist_egg.py", line 94, in finalize_options ei_cmd = self.ei_cmd = self.get_finalized_command("egg_info") File "/usr/lib/python2.4/distutils/cmd.py", line 319, in get_finalized_command cmd_obj.ensure_finalized() File "/usr/lib/python2.4/distutils/cmd.py", line 117, in ensure_finalized self.finalize_options() File "/usr/lib/python2.4/site-packages/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", line 85, in finalize_options self.vtags = self.tags() File "/usr/lib/python2.4/site-packages/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", line 179, in tags ): version += '-r%s' % self.get_svn_revision() File "/usr/lib/python2.4/site-packages/setuptools-0.6c2-py2.4.egg/setuptools/command/egg_info.py", line 196, in get_svn_revision dirurl = urlre.search(data).group(1) # get repository URL AttributeError: 'NoneType' object has no attribute 'group' Python 2.4.3 SVN Version 1.4.0 (r21228) Any ideas? -- mit freundlichen Grüßen email ~ m(a)tacker.org Markus Tacker url ~ http://m.tacker.org/ icq ~ 91709561

1 0

Re: [Distutils] Make ez_setup.py/easy_install $PATH aware
by Phillip J. Eby 17 Sep '06

17 Sep '06

At 02:38 PM 9/17/2006 +0100, Paul Moore wrote: >BTW, if you really want to make easy_install.exe available on the >command line without needing a PATH entry, you can do what python.exe >does: create a registry key > >HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\easy_install.exe > >with a single default value of the full pathname for the executable. >Then you don't need to muck with the user's PATH at all. For more >details, search for "App Paths" in the platform SDK - it gives the >full details. Unfortunately, the details it gives are wrong. Neither cmd.exe, command.com, nor bash will find a program registered this way, at least on my Win2K PC. This appears to *only* work for the Start/Run menu. Which isn't a bad start; I imagine that setuptools "GUI scripts" should be installed this way on Windows until/unless we get a way to give them menu entries or icons. A little further investigation reveals that typing "start whatever" in a command window will let you run something that's in "App Paths", *but* it will start in its own window, even if it's a console application. :( So, for console scripts, this still leaves something to be desired. As far as I can tell, *despite* what the MSDN docs say about App Paths, it is strictly a GUI facility and has no effect on command shells. (Interestingly, the lower-level SDK's show why - CreateProcess() ignores app paths, and only ShellExecute takes it into account. That's how I figured out that I could use the "start" command as well as the Start/Run menu option.)

4 4

Re: [Distutils] Make ez_setup.py/easy_install $PATH aware
by Phillip J. Eby 17 Sep '06

17 Sep '06

At 04:29 PM 9/17/2006 +0100, Paul Moore wrote: >On 9/17/06, Phillip J. Eby <pje(a)telecommunity.com> wrote: >>At 02:38 PM 9/17/2006 +0100, Paul Moore wrote: >> >BTW, if you really want to make easy_install.exe available on the >> >command line without needing a PATH entry, you can do what python.exe >> >does: create a registry key >> > >> >HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\easy_install.exe >[...] >>Unfortunately, the details it gives are wrong. Neither cmd.exe, >>command.com, nor bash will find a program registered this way, at least on >>my Win2K PC. This appears to *only* work for the Start/Run menu. Which >>isn't a bad start; I imagine that setuptools "GUI scripts" should be >>installed this way on Windows until/unless we get a way to give them menu >>entries or icons. >[...] >>As far as I can tell, *despite* what the MSDN docs say about App Paths, it >>is strictly a GUI facility and has no effect on command >>shells. (Interestingly, the lower-level SDK's show why - CreateProcess() >>ignores app paths, and only ShellExecute takes it into account. That's how >>I figured out that I could use the "start" command as well as the Start/Run >>menu option.) > >Sorry about that. I use 4NT, and it never occurred to me that CMD >didn't do this as well. Does this mean that on a standard PC, with >CMD.exe, typing "python" at he command prompt (with Python installed >from the standard installer) doesn't work???!?? > >[A quick test in VMWare later] > >Wow! It really doesn't! That seems, well, "less than ideal" :-( How >does anyone live with that? I guess command-line Python users on >Windows are used to needing to fix up PATH... Interestingly, I find that you can create an App Paths entry for cmd.exe that adds things to *its* path, but it only works if you start cmd using the "start" command or Start/Run. It doesn't work if you invoke cmd from another shell, nor does it help if you're using a different shell. Ugh. I think getting a workable command-line environment on Windows without end-user customization is an exercise in futility. :(

2 1

Make ez_setup.py/easy_install $PATH aware
by Ben Bangert 17 Sep '06

17 Sep '06

This is hopefully a pretty minor fix, and now that I think about it, I'm surprised it hasn't been in setuptools for ages. Some platforms don't have something setup right so that Python scripts are installed deep into Python library directories that definitely aren't in the $PATH. It becomes embarrassing as one tries to write "Install" instructions, and has to keep including a "Do you have any idea where the XXX command is? Try finding it and adding that dir to your path". Or having to tell people not to do anything without making a ~/.pydistutils.cfg file with a install-dir location. So.... couldn't ez_setup.py look at the $PATH present, and notice when the install location is outside of it? Then it could either give a nice big warning about how the scripts its about to install aren't going to be available without re-installing with the package and defining a install-dir for scripts, or adding the path to your $PATH. Surely there ought to be a better solution than blindly copying scripts into locations that will leave users wondering why they can't be run, and it seems like the system for that should be in ez_setup.py as thats a first step to getting the whole setuptools/ easy_install system going. Thanks, Ben

4 3

Re: [Distutils] Setuptools for Python 2.5
by Phillip J. Eby 15 Sep '06

15 Sep '06

At 10:19 PM 9/12/2006 +0100, Paul Moore wrote: >ez_setup won't install with Python 2.5c1 - presumably, because there >isn't a Python 2.5 egg available from the Cheeseshop. I'd have >expected it to build from sources in the absence of a suitable egg. Actually, that's not the reason. Python 2.5 requires setuptools 0.7a1, which is only available from SVN. >Given that it doesn't, how do I build and install setuptools on 2.5c1 >(on Windows)? I've downloaded and run setup.py bdist_egg, but how do I >get it installed "properly"? I could just build a bdist_wininst and >install that, but that's the "old way", and I want to try out the new >approach. setup.py install. Be sure to use the 0.7a1 version from the trunk. >Can anyone give me some hints? And would it be worth updating the >documentation with an explanation of how to handle this (dealing with >the lack of a published binary of a package for your specific version >of Python - how to find out what you need to build for yourself, where >to put things when you have built them, etc etc). "setup.py install" is the answer to this in the general case. >I have a sinking feeling that the next thing I'll hit is that once I >have setuptools installed, easy_install TurboGears (for example) will >also fail from lack of Python 2.5 binaries, and I'll be stuck again... Probably, unless you set up to use MinGW as your compiler or install the relevant MSVC goodies, so that they can be built from source. >[1] This is particularly frustrating, as setuptools is pure Python, so >why do I need a version-specific build? I don't with bdist_wininst.... One reason why is that setuptools configures its installation differently for different Python versions; there are entry points, for example, that are registered differently for Python 2.3, 2.4, and 2.5. Some packages can have different dependencies, based on Python version too. For example, a package needing ctypes for Python 2.3 or 2.4 shouldn't include the dependency when built for Python 2.5, as ctypes is in the stdlib there.

3 4

HOwto download only egg's with setuptools/EasyInstall
by "Anton Müller" 15 Sep '06

15 Sep '06

Hi, I would like to know if I can use EasyInstall to *download only* an egg file+ all its dependencies in a folder. Concrete example: I would like to download TurboGears egg and all other eggs it needs but without installing it at once. I didn't find a switch (the editable option was not what I needed). Is there some hint or: - do I need to use a downloadmanager (I did it last time but you have to filter out manually what you dont want because on the TurboGears downloadpage there are all old beta's too ... and some eggs are missing here ...) - do I have to write myself a python script analysing the egg header and and and (perhaps it exist already??) A small advice would be nice :-) Anton -- "Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

5 7

Is this a reasonable place to discuss zc.buildout? Or do I need to make a separate list?
by Jim Fulton 13 Sep '06

13 Sep '06

zc.buildout, http://www.python.org/pypi/zc.buildout, is a system for: - Assembling applications consisting of many programs, Python and otherwise, possibly distributed over muiltiple machines, and for - Managing eggs not installed into system Python installations. Buildout is complementary to easy_install. While easy_install is great for simply installing eggs into a system Python in a highly automated and simple way, buildout is great when: - You need more control over the eggs used, - Different applications need different egg versions, - You are developing an application and don't want to (or can't) modify a Python installation, - You want isolation between different applications sharing a single Python installation. Like easy_install, zc.buildout builds on setuptools. Buildout is still fairly early in it's development and is still evolving. Lots of people are trying it out and providing feedback, which is great. Right now, people send me questions individually. This means that others can't benefit from their questions or their answers. IOW, I need a mailing list. I hate to create yet another mailing list and wonder if this list would be a reasonable place for people to discuss zc.buildout. Would anyone object if I directed zc.buildout discussions here? Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 1

Re: [Distutils] Setuptools for Python 2.5
by Phillip J. Eby 12 Sep '06

12 Sep '06

At 11:26 PM 9/12/2006 +0100, Paul Moore wrote: >On 9/12/06, Phillip J. Eby <pje(a)telecommunity.com> wrote: >>Actually, that's not the reason. Python 2.5 requires setuptools 0.7a1, >>which is only available from SVN. > >Ah. In that case, the error is misleading but at least the solution is >straightforward :-) But I built and installed 0.6c2 as a bdist_wininst >and things seemed to be sort-of working. What actually goes wrong? >Something clearly does, but it's far from obvious... To be honest, I've completely forgotten at this point. You could skim the "svn log" looking for things related to Python 2.5 if it really matters. :) I just remember that I had to make changes. Some were minor things, like Python 2.5 distutils including its own "upload" command, and others were more substantial, possibly related to other distutils changes or to language changes. >>setup.py install. Be sure to use the 0.7a1 version from the trunk. > >OK, cool. Does the fact that I can use setup.py install also mean I >can just build a bdist_wininst and install that? That was what the >single-version-externally-managed format was about, yes? If so, do I >miss out on any of the multi-version features by doing things this >way? Nope. There are only two things that the SVEM format can't do (besides being uninstalled without a packaging system): 1. It can't include __init__.py for "namespace packages" (packages like peak.* and zope.* that are split across separate distributions). You can have namespace packages, mind you, it's just that you can't include anything in the __init__.py for the package, because it's not installed when a SVEM installation is done. 2. Project-level data files, i.e., resources in the "root" of an egg. There's no way for you to access these resources if a project is installed SVEM, because there's no per-project directory for that stuff to go in. These are both extremely rare things to have in a project. >Fair enough. Presumably, as automatic building from source should have >worked, this doesn't imply a higher dependency on distributors >providing binary eggs than the old approach did. Correct.

1 0

Setuptools for Python 2.5
by Paul Moore 12 Sep '06

12 Sep '06

ez_setup won't install with Python 2.5c1 - presumably, because there isn't a Python 2.5 egg available from the Cheeseshop. I'd have expected it to build from sources in the absence of a suitable egg. Given that it doesn't, how do I build and install setuptools on 2.5c1 (on Windows)? I've downloaded and run setup.py bdist_egg, but how do I get it installed "properly"? I could just build a bdist_wininst and install that, but that's the "old way", and I want to try out the new approach. After I've built the egg, running ez_setup from the setuptools build directory says that setuptools is already installed. Presumably because it's adding the current directory to sys.path, and setuptools *is* in the current directory... I could probably work all this out with some effort from the existing documentation, but that's not my point. I've skimmed the docs, tried ez_setup as described, hit an issue because there's no version-specific build[1] and then hit a wall, as there aren't any pointers as to where to go from here. Can anyone give me some hints? And would it be worth updating the documentation with an explanation of how to handle this (dealing with the lack of a published binary of a package for your specific version of Python - how to find out what you need to build for yourself, where to put things when you have built them, etc etc). I have a sinking feeling that the next thing I'll hit is that once I have setuptools installed, easy_install TurboGears (for example) will also fail from lack of Python 2.5 binaries, and I'll be stuck again... Thanks, Paul. [1] This is particularly frustrating, as setuptools is pure Python, so why do I need a version-specific build? I don't with bdist_wininst....

1 0

[setuptools] best way to create offline install bundles?
by Kevin Dangoor 12 Sep '06

12 Sep '06

I've had quite a few complaints over the months from people who are stuck behind firewalls and can't install TurboGears with easy_install for whatever reason. This problem is somewhat compounded in cases where the user may have a machine that has internet access, but isn't the same platform as their deployment machine so they wouldn't even get the right eggs to deploy with easy_install. What I ultimately want to end up with is a tarball that contains all of the platform independent stuff, and then three tarballs for the platform dependent stuff (win, mac, source). I know about easy_install -zmaxd, and that certainly helps... but 1) it doesn't keep all of the eggs zipped up (because it sitll thinks it's doing an install, instead of just a download) 2) it doesn't help with the three platform dependent parts Is this something zc.buildout can help with? I'm not certain what the best way is to automate this process... Thanks, Kevin -- Kevin Dangoor TurboGears / Zesty News email: kid(a)blazingthings.com company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com

4 7