Mailman 3 October 2005 - Distutils-SIG

Bugginess in distutils.core.run_setup?
by Arve Knudsen 18 Oct '05

18 Oct '05

Sorry if this has been asked before, but I'm having difficulties in using the distutils.core.run_setup function. Setup scripts that will work happily when run from the commandline ("python setup.py") bomb out when under run_setup. What happens as far as I can tell is that run_setup provides a "locals" argument for execfile, which is used for "import" statements. What happens then is that imports on the global level are not visible to functions, so an exception is raised when a function tries to access a globally imported module. Is this due to faulty logic in run_setup (explicitly specifying the "locals" argument)? Thanks Arve Knudsen

2 2

0.6a6 in CVS (was Re: egg_info needs to hit the net?)
by Phillip J. Eby 17 Oct '05

17 Oct '05

At 10:17 PM 10/16/2005 -0400, Kevin Dangoor wrote: >On 10/16/05, Phillip J. Eby <pje(a)telecommunity.com> wrote: > > setup_requires never causes anything to be *installed* on the target > > system. It's just downloaded to the project directory so the setup script > > can use it. It sounds like you need to also list it in TurboGears' > > "install_requires" in this case. Then it'll be installed on the system, > > and new projects won't need to download it. > >That explains a lot. Thanks! No problem. I've added a note about this to the docs in CVS now. By the way, I've also just checked in 0.6a6, which I think should be able to handle all the custom Unix install stuff you can throw at it. It's a major update to the installation instructions, and a 'virtual-python' script based on Ian's contribution is included. And of course there are various bugfixes, etc. I'd appreciate it if you could take it for a spin on a few platforms before I release it, since TurboGears users seem to be my biggest group of "customers" at the moment, especially for non-root Unix installs. And of course, I'd love to get feedback from anybody else, not just Kevin. :)

1 0

Re: [Distutils] egg_info needs to hit the net?
by Phillip J. Eby 17 Oct '05

17 Oct '05

At 09:20 PM 10/16/2005 -0400, Kevin Dangoor wrote: >On 10/16/05, Phillip J. Eby <pje(a)telecommunity.com> wrote: > > At 07:56 PM 10/16/2005 -0400, Kevin Dangoor wrote: > > >TurboGears quickstart now does an "egg_info" on the newly-created > > >project. Someone just reported that he got a "Connection Refused" > > >exception and was reasonably wondering why it needed to hit the net in > > >order to start a new project. > > > > It's not egg_info that's the problem. The issue is running a setup.py that > > has a 'setup_requires' argument. If the required thing isn't installed, > > then setup.py goes looking for it. It just so happens in this case that > > 'egg_info' is the command, but you could've run 'setup.py --help' and the > > same thing would happen. You should make sure that tg-admin quickstart > > installs any setup_requires targets that are in the quickstart template, or > > else this will happen with every new project. > >I believe TurboGears itself has the same setup_requires. Wouldn't >installing TurboGears itself get you the required package? setup_requires never causes anything to be *installed* on the target system. It's just downloaded to the project directory so the setup script can use it. It sounds like you need to also list it in TurboGears' "install_requires" in this case. Then it'll be installed on the system, and new projects won't need to download it.

2 1

Re: [Distutils] egg_info needs to hit the net?
by Phillip J. Eby 17 Oct '05

17 Oct '05

At 07:56 PM 10/16/2005 -0400, Kevin Dangoor wrote: >TurboGears quickstart now does an "egg_info" on the newly-created >project. Someone just reported that he got a "Connection Refused" >exception and was reasonably wondering why it needed to hit the net in >order to start a new project. > >I've gathered that the cheeseshop was down today and this is why the >connection was refused, but I am interested to know why egg_info >requires net access. It's not egg_info that's the problem. The issue is running a setup.py that has a 'setup_requires' argument. If the required thing isn't installed, then setup.py goes looking for it. It just so happens in this case that 'egg_info' is the command, but you could've run 'setup.py --help' and the same thing would happen. You should make sure that tg-admin quickstart installs any setup_requires targets that are in the quickstart template, or else this will happen with every new project.

2 1

egg_info needs to hit the net?
by Kevin Dangoor 17 Oct '05

17 Oct '05

TurboGears quickstart now does an "egg_info" on the newly-created project. Someone just reported that he got a "Connection Refused" exception and was reasonably wondering why it needed to hit the net in order to start a new project. I've gathered that the cheeseshop was down today and this is why the connection was refused, but I am interested to know why egg_info requires net access. Thanks, Kevin -- Kevin Dangoor Author of the Zesty News RSS newsreader email: kid(a)blazingthings.com company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com

1 0

Using setuptools without root permissions
by Raul Murciano 14 Oct '05

14 Oct '05

Hi all, I'm trying to install TurboGears by using EasyInstall [1] on a FreeBSD shared host (Textdrive). I have not root permissions, so following PEAK's instructions [2] I've executed Ian Bicking's non_root_python.py script. The script seems to work perfectly, it outputs no errors and: Setuptools version 0.6a5 or greater has been installed. (Run "ez_setup.py -U setuptools" to reinstall or upgrade.) I've checked that ~/bin/ contains python (my custom python) and easy_install executables. Now I try: ~/bin/python >>> import setuptools Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named setuptools I've checked the path: ~/bin/python >>> import sys >>> sys.path ['', '/home/murciano/lib', '/home/murciano/lib/python2.4/site-packages', '/home/murciano/lib/python24.zip', '/home/murciano/lib/python2.4', '/home/murciano/lib/python2.4/plat-freebsd5', '/home/murciano/lib/python2.4/lib-tk', '/home/murciano/lib/python2.4/lib-dynload', '/home/murciano/lib/python2.4/site-packages/Numeric', '/home/murciano/lib/python2.4/site-packages/PIL'] And if I insert the setuptools-egg path by hand things works: >>>sys.path.insert(0,"/home/murciano/lib/python2.4/site-packages/setuptools-0.6a5-py2.4.egg") >>>import setuptools >>> I have the same problem with pkg_resources, so I can't execute TurboGears properly. Any help/idea/suggestion would be welcome :-) Greetings, Raul Murciano [1] TurboGears installation for *nix: http://turbogears.org/download/nix.html [2] PEAK EasyInstall non-root installation: http://peak.telecommunity.com/DevCenter/EasyInstall#non-root-installation

2 2

Re: [Distutils] pkg_resources.iter_entry_points() and pkg_resources.require
by Phillip J. Eby 14 Oct '05

14 Oct '05

At 09:08 AM 10/13/2005 +0200, Elvelind Grandin wrote: >I'm having a go at using entry points for the plugin system for an app >I'm working on. All is working good .. exept when the plugins are >installed localy, then I need to require them before they will turn up >in iter_entry_points(), which ofcourse breaks everything. >Is this a good way around this? Some applications handle plugins by adding every egg in a "plugins" directory to the working set, e.g.: working_set.add_entry(plugins_dir) env = Environment([plugins_dir]) working_set.require(*env.keys()) This first adds the plugins directory to the directories in the working set, so that items in the plugin directory can be found. It then scans the plugin directory to create an environment, which is a table mapping project names to available distributions for that project. Finally, it require()'s all the projects that have eggs in the plugins directory. At this point, the working set will be populated with all the plugins, although nothing will have been imported. You can then use iter_entry_points() or any other APIs to access your plugins. The alternative strategy is to require plugins to be installed in a "site" directory using easy_install, in which case they will be listed in a .pth file and thus be part of the working set as soon as pkg_resources is imported.

1 0

pkg_resources.iter_entry_points() and pkg_resources.require
by Elvelind Grandin 13 Oct '05

13 Oct '05

I'm having a go at using entry points for the plugin system for an app I'm working on. All is working good .. exept when the plugins are installed localy, then I need to require them before they will turn up in iter_entry_points(), which ofcourse breaks everything. Is this a good way around this? -- cheers elvelind grandin

1 0

resource_filename() breaks cxfreeze (py2exe?)
by Robby Dermody 13 Oct '05

13 Oct '05

Hi guys, The subject line no doubt tells you all something you already know. This morning, I didn't even know that setuputils existed, so excuse my ignorance on the topic. Basically, I have an application that makes use of a python web application development library called nevow. The current version of nevow (0.5.0) makes use of resource_filename() to get the paths of certain static files that it uses. Things work fine when my app is not frozen, but after I freeze it with cx_freeze resource_filename() turns out to be a breakage point. I would think the same kind of thing would happen with py2exe. See the traceback at the end of this message for more info. Once I freeze the application and run it, my sys.path is set to ['/home/robbyd/dev/inquest/dist/inquest-director-0.7.0-1/inquest-director', '/home/robbyd/dev/inquest/dist/inquest-director-0.7.0-1'] (Meaning the frozen zip file executable, 'inquest-director', and its parent path.) Normally this works fine, due to zipimporter. However, with the static files nevow is attempting to locate with resource_filename(), it seems that the problem is that, resource_filename() wants to look into the zip file but it doesn't know how to do so. (I have not done too much research into how this function works, so I may be missing the point here.) What I'd like to know is why this is the case, and what may happen when resource_filename() gets used in more libraries whose users freeze their applications with cxfreeze/py2exe/macmillian/etc. Is this a move by setuptools to take over the world (of python packaging utilities)? ;) Thanks in advance for any feedback that is offered. At this point I'm just unsure if this is more of a setuptools issue, or more of a cx_Freeze issue. I did take a look at setuptools and I was impressed with it, but my app has certain requirements that make cx_freeze a good choice. Robby ------ Here's the traceback that I get, with the specific error (note that util.resource_filename in webform.py is just an alias to pkg_resource.resource_filename): Traceback (most recent call last): File "/home/robbyd/downloads/cx_Freeze-3.0.1/initscripts/Console.py", line 26, in ? exec code in m.__dict__ File "dist/src/inquest/director/director.py", line 33, in ? File "/home/robbyd/dev/inquest/dist/src/inquest/director/util/twistednet.py", line 22, in ? from nevow import inevow, static File "/usr/lib/python2.3/site-packages/nevow/__init__.py", line 140, in ? load(basic_adapters) File "/usr/lib/python2.3/site-packages/nevow/__init__.py", line 30, in load compy.registerAdapter(a, clean(o), i) File "/usr/lib/python2.3/site-packages/nevow/compy.py", line 32, in registerAdapter adapterFactory = _namedAnyWithBuiltinTranslation(adapterFactory) File "/usr/lib/python2.3/site-packages/nevow/util.py", line 225, in _namedAnyWithBuiltinTranslation return namedAny(name) File "/usr/lib/python2.3/site-packages/nevow/util.py", line 78, in namedAny topLevelPackage = __import__(trialname) File "/usr/lib/python2.3/site-packages/formless/webform.py", line 42, in ? defaultCSS = File(util.resource_filename('formless', 'freeform-default.css'), 'text/css') File "/usr/lib/python2.3/site-packages/setuptools-0.5a13-py2.3.egg/pkg_resources.py", line 676, in resource_filename return get_provider(package_or_requirement).get_resource_filename( File "/usr/lib/python2.3/site-packages/setuptools-0.5a13-py2.3.egg/pkg_resources.py", line 1056, in get_resource_filename raise NotImplementedError( NotImplementedError: resource_filename() only supported for .egg, not .zip

2 1

Re: [Distutils] setuptools in a cross-compilation packaging environment
by Phillip J. Eby 12 Oct '05

12 Oct '05

At 08:45 PM 10/11/2005 +0100, Paul Moore wrote: >Integrate with platform-specific installers (in my specific case, >bdist_wininst) so that the "list all packages" command (for example) >lists *everything* installed, egg or not. Feel free to implement that; I just don't offer an API that knows about arbitrarily installed things, since there isn't any reliable way (that I know of) to know that. :) >(This is the one that I view as a key requirement, and the one that >I've never managed to get a decent start on - if I had, I might have >delivered on my offer to produce some management scripts by now!) My take on it is that if there are compelling reasons to use eggs (such as great package management tools), then sooner or later everyone will use eggs, and the legacy problem will take care of itself. EasyInstall also gives you the option to get rid of legacy packages when you install an egg of the same package. >And a couple of cases like that, where the egg >conversion is imperfect, are enough to leave me thinking that life's >too short, and go back to using the installer direct, and only even >considering eggs when they are offered by the author, "officially". Which is quite reasonable, and certainly doesn't make you any worse off than you already are. When enough packages use eggs, and more package management tools for eggs exist, this balance will shift. It's just going to take time. EasyInstall didn't even exist six months ago, and the pkg_resources runtime was still under construction. >PS I'm very interested in trying out TurboGears, which comes as an >egg-enabled package, automatically grabbing its dependencies. But I'm >scared to do so until I can set up a sandbox machine, as *all* of the >machines I use regularly have at least one of TurboGears' dependencies >installed as a non-egg, and I don't want the easy_install stuff to >mess those up, nor do I want to uninstall my existing packages. Ironic >that a system designed to make installations with dependencies >*easier* has resulted in me being unable to "just try it out"... If you're using a Unix machine, just use the "Non-Root Installation" procedure, or Ian Bicking's sandbox creation script, to set up a "virtual Python". Unfortunately, on Windows this is less than practical due to the lack of symlinks. Later 0.6 releases of setuptools, however, are going to make it trivial to install packages to other directories than site-packages, while avoiding any conflict with already-installed packages. The target directory will have to be either a script/launch directory or else a PYTHONPATH directory, but other than that you'll have the full flexibility that you get when installing to site-packages now. The issue right now is that pkg_resources always adds eggs to the *end* of sys.path, but future versions will add eggs in front of their parent directory on sys.path. There will also be a facility to create a dummy site.py to force Python to pay attention to easy-install.pth in the target directory, no matter what the target directory is.

1 0