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)?
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
And of course, I'd love to get feedback from anybody else, not just Kevin. :)
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.
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.
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.
Author of the Zesty News RSS newsreader
I'm trying to install TurboGears by using EasyInstall  on a FreeBSD
shared host (Textdrive). I have not root permissions, so following
PEAK's instructions  I've executed Ian Bicking's non_root_python.py
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:
>>> import setuptools
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ImportError: No module named setuptools
I've checked the path:
>>> import sys
['', '/home/murciano/lib', '/home/murciano/lib/python2.4/site-packages',
And if I insert the setuptools-egg path by hand things works:
I have the same problem with pkg_resources, so I can't execute
TurboGears properly. Any help/idea/suggestion would be welcome :-)
 TurboGears installation for *nix:
 PEAK EasyInstall non-root installation:
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.:
env = Environment([plugins_dir])
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.
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?
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
Once I freeze the application and run it, my sys.path is set to
(Meaning the frozen zip file executable, 'inquest-director', and its
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
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
Here's the traceback that I get, with the specific error (note that
util.resource_filename in webform.py is just an alias to
Traceback (most recent call last):
line 26, in ?
exec code in m.__dict__
File "dist/src/inquest/director/director.py", line 33, in ?
line 22, in ?
from nevow import inevow, static
File "/usr/lib/python2.3/site-packages/nevow/__init__.py", line 140, in ?
File "/usr/lib/python2.3/site-packages/nevow/__init__.py", line 30, in
compy.registerAdapter(a, clean(o), i)
File "/usr/lib/python2.3/site-packages/nevow/compy.py", line 32, in
adapterFactory = _namedAnyWithBuiltinTranslation(adapterFactory)
File "/usr/lib/python2.3/site-packages/nevow/util.py", line 225, in
File "/usr/lib/python2.3/site-packages/nevow/util.py", line 78, in
topLevelPackage = __import__(trialname)
File "/usr/lib/python2.3/site-packages/formless/webform.py", line 42, in ?
defaultCSS = File(util.resource_filename('formless',
line 676, in resource_filename
line 1056, in get_resource_filename raise NotImplementedError(
NotImplementedError: resource_filename() only supported for .egg, not .zip
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.