[Distutils] Twisted and easy_install
I'm having trouble doing an install of the newest Twisted from the
Cheeseshop, using easy_install. I took a quick look through the
archives of distutils-sig, and couldn't find anything. I'm running on
OS X 10.3.9, latest version of setuptools (did an 'easy_install -U
setuptools' right before I tried installing Twisted). I've pasted the
result below. Any thoughts?
Searching for twisted
Reading http://www.python.org/pypi/twisted/
Couldn't find index page for 'twisted' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://www.python.org/pypi/
Reading http://www.python.org/pypi/Twisted/2.1.0
Reading http://www.twistedmatrix.com
Reading http://twistedmatrix.com/projects/core/
Best match: Twisted 2.1.0
Downloading http://tmrc.mit.edu/mirror/twisted/Twisted/2.1/Twisted-2.1.0.tar.bz2
Processing Twisted-2.1.0.tar.bz2
Running Twisted-2.1.0/setup.py -q bdist_egg --dist-dir
/tmp/easy_install-ssfbd7/Twisted-2.1.0/egg-dist-tmp--DvGj-
Traceback (most recent call last):
File /Library/Frameworks/Python.framework/Versions/2.4/bin/easy_install,
line 7, in ?
sys.exit(
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/setuptools/command/easy_install.py,
line 1138, in main
setup(script_args = ['-q','easy_install', '-v']+argv, **kw)
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/core.py,
line 149, in setup
dist.run_commands()
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py,
line 946, in run_commands
self.run_command(cmd)
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py,
line 966, in run_command
cmd_obj.run()
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/setuptools/command/easy_install.py,
line 230, in run
self.easy_install(spec, not self.no_deps)
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/setuptools/command/easy_install.py,
line 317, in easy_install
return self.install_item(spec, download, tmpdir, deps)
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/setuptools/command/easy_install.py,
line 338, in install_item
dists = self.install_eggs(spec, download, tmpdir)
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/setuptools/command/easy_install.py,
line 532, in install_eggs
return self.build_and_install(setup_script, setup_base)
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/setuptools/command/easy_install.py,
line 807, in build_and_install
self.run_setup(setup_script, setup_base, args)
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/setuptools/command/easy_install.py,
line 796, in run_setup
run_setup(setup_script, args)
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/setuptools/sandbox.py,
line 26, in run_setup
DirectorySandbox(setup_dir).run(
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/setuptools/sandbox.py,
line 63, in run
return func()
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/setuptools/sandbox.py,
line 29, in lambda
{'__file__':setup_script, '__name__':'__main__'}
File setup.py, line 113, in ?
File ./twisted/python/dist.py, line 69, in setup
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/core.py,
line 149, in setup
dist.run_commands()
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py,
line 946, in run_commands
self.run_command(cmd)
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py,
line 966, in run_command
cmd_obj.run()
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/setuptools/command/bdist_egg.py,
line 167, in run
self.run_command(egg_info)
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/cmd.py,
line 333, in run_command
self.distribution.run_command(command)
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/distutils/dist.py,
line 966, in run_command
cmd_obj.run()
File
/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/setuptools/command/egg_info.py,
line 129, in run
writer(self, ep.name, os.path.join(self.egg_info,ep.name))
File
[Distutils] Easy install, making Traditional PYTHONPATH-based Installation work better
I'be been learning about setuptools and eggs and am very pleased. There is one area where I'd like to see a small tweak. In: http://peak.telecommunity.com/DevCenter/EasyInstall#custom-installation-locations four options are presented for installing outside of Python installation. Naturally, I prefer the the last option, which the documentation recommends against. :) Here's why. An important use case to me is the ability for a developer to work in a development sandbox without affecting anything outside the sandbox. The solution needs to be cross platform. The Administrator Installation option doesn't work for me because it requires modifying the Python setup. Neither the Mac OS X User Installation nor the 'Creating a Virtual Python' options work for me because they are not cross platform. I also find the Virtual Python approach a bit heavy handed. In playing a bit, I find the Traditional PYTHONPATH-based Installation works pretty well except for the problem of having to set the path manually when invoking scripts. This problem could be addressed by having the generated scripts include the custom path settings. I recommend adding two new options to the easy_install section of the configuration file: script_path A list of paths, separated by commas to be added to sys.path by generated scripts. script_pth_files A list of pth files, separated by commas to be added be processed by script files. Generated scripts would include code to manipulate sys.path based on this information. So, for example, in a workspace with a 'lib' directory containing eggs, I'd have: [easy_install] site_dirs = '/here/lib' script_path = '/here/lib' script_pth_files = '/here/lib/easy-install.pth' The script_pth_files option is needed, I think, to avoid hardcoding the setuptools egg path in the generated scripts. Note that it could be argued that the site_dirs option should be enough and that generated scripts should simply reflect this option. Thoughts? For now, I can create a wrapper around easy_install that does custom script generation, which could serve as a prototype for the proposed change. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Easy install, making Traditional PYTHONPATH-based Installation work better
At 10:52 AM 2/5/2006 -0500, Jim Fulton wrote: I'be been learning about setuptools and eggs and am very pleased. There is one area where I'd like to see a small tweak. In: http://peak.telecommunity.com/DevCenter/EasyInstall#custom-installation-locations four options are presented for installing outside of Python installation. Naturally, I prefer the the last option, which the documentation recommends against. :) Here's why. An important use case to me is the ability for a developer to work in a development sandbox without affecting anything outside the sandbox. The solution needs to be cross platform. The Administrator Installation option doesn't work for me because it requires modifying the Python setup. Neither the Mac OS X User Installation nor the 'Creating a Virtual Python' options work for me because they are not cross platform. I also find the Virtual Python approach a bit heavy handed. In playing a bit, I find the Traditional PYTHONPATH-based Installation works pretty well except for the problem of having to set the path manually when invoking scripts. This problem could be addressed by having the generated scripts include the custom path settings. Unfortunately, that's probably harder than you think. The reason I advise against the PYTHONPATH-based approach is that it uses a sneaky hack to get site directory processing to work properly (i.e., as desired). When you use the PYTHONPATH-based approach, it only works if you put the setuptools egg directly on the PYTHONPATH at *Python startup*, because setuptools includes its own version of the 'site' module that bypasses the standard Python 'site' module, so that it can scan .pth files that are *already on* PYTHONPATH. This means that no Python code embedded in the scripts is going to affect this. If you want to use PYTHONPATH, you have to set PYTHONPATH in the environment. By the time the Python script itself is running, sys.path has already been manipulated such that it's no longer possible to process .pth files in a way that gives them precedence over system-installed packages. Now, if you don't care about the .pth files and just want to use whatever the script's require() picks up, then it's not a problem. However, since your post talked about .pth and site-dirs, I assumed that means you want to process that stuff. For now, I can create a wrapper around easy_install that does custom script generation, which could serve as a prototype for the proposed change. Try it out, and see if you can get a privately installed package to *override* a system-installed one, without setting PYTHONPATH in the environment prior to Python startup. I'll be surprised and intrigued if you can find a way. (*Adding* packages this way is of course easy; it's overriding system-installed packages that's the problem, because you have to get the .pth stuff in *front* of site-packages in sys.path, and that normally doesn't happen. It only happens with setuptools because of its hacked 'site.py'.) If you don't care about .pth files, then you can simply install the desired eggs or egg-links to the same directory as the scripts, and PYTHONPATH only needs to include the setuptools egg. It's either that, or perhaps put some bootstrap code in every script to locate setuptools if it's not already on sys.path. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Twisted and easy_install
On Feb 5, 2006, at 10:22 AM, Phillip J. Eby wrote: At 07:05 AM 2/5/2006 -0800, Jay Parlar wrote: I'm having trouble doing an install of the newest Twisted from the Cheeseshop, using easy_install. I took a quick look through the archives of distutils-sig, and couldn't find anything. I'm running on OS X 10.3.9, latest version of setuptools (did an 'easy_install -U setuptools' right before I tried installing Twisted). I've pasted the result below. Any thoughts? [...] AttributeError: 'bool' object has no attribute 'name' Twisted does some interesting mangling of the build_ext process in order to support optional extensions, that are only determined at build time. I've been meaning to add a facility to do this in setuptools, but it's not done yet, and in any case Twisted would have to *use* that facility in order for it to work. I'm afraid Twisted isn't supportable by easy_install at the present time. Not only that, but the top-level script for Twisted isn't distutils based. It is a script that invokes several setup.py files for each of the subprojects if given build or install as options, and otherwise takes totally different arguments. Even if it did install with easy_install it would be a little misleading since Twisted requires Zope.Interface and has a bunch of extras (like SSL or serial support). Twisted really could use a good refactor to support setuptools, but the core team isn't interested in doing that. I believe Zope.Interface is not compatible with setuptools also. I'm not sure why... I think it's the distribution name or something. -bob ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Twisted and easy_install
On 2/5/06, Bob Ippolito [EMAIL PROTECTED] wrote: On Feb 5, 2006, at 10:22 AM, Phillip J. Eby wrote: [snip] Twisted does some interesting mangling of the build_ext process in order to support optional extensions, that are only determined at build time. I've been meaning to add a facility to do this in setuptools, but it's not done yet, and in any case Twisted would have to *use* that facility in order for it to work. I'm afraid Twisted isn't supportable by easy_install at the present time. Not only that, but the top-level script for Twisted isn't distutils based. It is a script that invokes several setup.py files for each of the subprojects if given build or install as options, and otherwise takes totally different arguments. Even if it did install with easy_install it would be a little misleading since Twisted requires Zope.Interface and has a bunch of extras (like SSL or serial support). Twisted really could use a good refactor to support setuptools, but the core team isn't interested in doing that. I believe Zope.Interface is not compatible with setuptools also. I'm not sure why... I think it's the distribution name or something. That's more or less what I figured. I mostly wanted to post the error message because it's non-obvious what went wrong, and wanted to make sure someone in the know saw it. I think I still remember how to install packages the old fashioned way, something or other about 'setup.py install' :) Jay P. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Easy install, making Traditional PYTHONPATH-based Installation work better
At 02:16 PM 2/5/2006 -0500, Jim Fulton wrote: It's too bad setuptools isn't in the standard library. If it was, I'd probably just stick all my eggs and scripts in the same place and be done ith it. :) It's still tempting. Note that it's only actually necessary for *pkg_resources* to be importable; you don't have to have all of setuptools. If you installed pkg_resources.py to your target directory, your whole plan would work just fine. By the way, note that if people are developing from source, you probably want to use 'setup.py develop' rather than 'easy_install', since it allows you to edit the code and continue to run. The 'develop' command should work the same with all this, just make sure there's a pkg_resources.py in the target directory when you actually run your scripts. Indeed, given your requirements as I understand them, that should really be all you need. You don't need a custom site-dirs, you need only configure the installation directory (--install-dir) for easy_install and develop. Develop inherits configuration from easy_install, so a ~/.pydistutils.cfg like this: [easy_install] install_dir = wherever should do the trick as long as wherever/pkg_resources.py exists. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Pythonmac-SIG] pkg_resources and Mac OS X compatibility
On Feb 5, 2006, at 2:00 PM, Bob Ippolito wrote: With the way that we're returning the distutils platform on the universal branch of Mac OS X, we need another patch to pkg_resources. The reason for this is that distutils.util.get_platform() returns the platform that it is trying to produce binaries for, which is often not the exact current platform. More specifically, our current strategy is to produce a version of Python that will build extensions that are compatible with Mac OS X 10.3, but the actual building of extensions requires Mac OS X 10.4 or later (because the toolchain doesn't exist on Mac OS X 10.3). In some rare cases, people will want to produce packages that explicitly require Mac OS X 10.4 or later, which they can do by setting the MACOSX_DEPLOYMENT_TARGET=10.4 environment variable when running setup.py. This will influence the value returned by disutils.util.get_platform(), and will influence the compiler and linker if extensions are built. This patch adds an internal _get_max_platform(plat) function that returns the actual runtime version of Mac OS X, for use in compatible_platforms. Oops, wrong patch.. here's the correct one. Sorry about that: -bob setuptools-r42250-fat-1.patch Description: Binary data ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
