Mailman 3 October 2006 - Distutils-SIG

More Windows questions
by Phillip J. Eby Oct. 4, 2006

Oct. 4, 2006

Okay, I've looked at the registry a bit, and it seems like I can register App Paths either under HKLM (for the whole machine) or under HKCU (for the current user). However, both seem to have issues. Under later versions of Windows, especially when not running with administrative privileges, the HKLM keys will probably be off limits, and might generate warning popups of various kinds. On the other hand, HKCU might not be that useful for a system-wide Python installation, and would seem to force you to repeatedly reinstall for each user. I could ask the user, but they're not really any more likely to know what to do either, and in any case I'm thinking that for 0.6 I'd prefer to keep the installation code as simple as possible. (Which means I don't want to even bother with a dialog, and will therefore just skip the .egg registration idea.) Examining this a little further, I notice that there are a couple of problems with setuptools generating bdist_wininst installers right now: 1. The "-script.py" files don't get their #! lines updated, so if the destination machine has Python in a different location than on the generating machine, the wrapper .exe's won't work. 2. If you generate a bdist_wininst on a non-Windows platform, you don't get the "-script.py" and ".exe" wrappers to begin with. So, here's what I'm thinking I should do. First, setuptools' bdist_wininst should always generate -script.py and .exe wrappers, so that you can build correctly on non-Windows platforms. Second, setuptools' bdist_wininst should add its own postinstall script that: 1. Updates the #! lines in the installed scripts to point to the right executable 2. Register HKCU "App Paths" entries for all console scripts, pointing to a second '-conio-.exe' wrapper for the same '-script.py', thus allowing console scripts to be run from the "Start/Run" command line. (Note that easy_install could and maybe should do the same when run on Windows, but could have a command-line option to disable it, like --no-register or something.) The net result would be that on Windows, the command-line would become at least somewhat useful. If you are already in a command shell, "start foo args" will run the console script in a new window, without needing you to modify PATH or the default installation location(s). This isn't perfect, but as an "out of the box" usability experience for the Windows command line, it would beat the heck out of what we have now. Any thoughts?

3 4

Draft of new setuptools installation instructions
by Phillip J. Eby Oct. 3, 2006

Oct. 3, 2006

I'm working on new installation instructions for setuptools 0.6c4, which will no longer use ez_setup.py for end-user manual installation of setuptools (as opposed to bundled installation with another package). The basic idea is that the PyPI page for setuptools would contain these instructions, and links to the various setuptools documentation pages. ez_setup will still be available for as an importable module for people to integrate with their setuptools-using packages, but when run as a script, ez_setup.py will simply tell people to consult the PyPI page. I'm looking for any feedback people might have, on the installation process itself or on the directions. Some particular areas of question/concern: * Should ez_setup perhaps launch a web browser pointing to these instructions, instead of trying to download setuptools itself? (This would bypass most of those annoying proxy problems right off the bat, at least when just installing setuptools.) * Should we make more effort to create a usable command-line experience on Windows? Perhaps use a post-install script to register easy_install so it works from "Start/Run", with an automatic pause to prevent the opened console window from closing when it finishes running? Should we include optional registration for the ``.egg`` extension so downloading or double-clicking an egg installs it? * The new install procedure bypasses firewall issues for installing setuptools itself, but doesn't do anything about the issue for packages that have dependencies. Is there anything else that can be done about that? Anyway, those are the questions; here are the docs so far: ------------------------- Installation Instructions ------------------------- Windows ======= Install setuptools using the provided ``.exe`` installer. If you've previously installed older versions of setuptools, please delete all ``setuptools*.egg`` files from your system FIRST. If you are upgrading a previous version of setuptools that was installed using an ``.exe`` installer, please be sure to also uninstall that older version via your system's "Add/Remove Programs" feature, BEFORE installing the newer version. RPM-Based Systems ================= Install setuptools using the provided source RPM. The included ``.spec`` file assumes you are installing using the default ``python`` executable, and is thus not specific to a particular Python version. The ``easy_install`` executable will be installed to a system ``bin`` directory such as ``/usr/bin``. If you wish to install to a custom installation location, please use the ``.egg`` installation approach described in the following section. Cygwin, Mac OS X, Linux, Other ============================== 1. Download the appropriate egg for your version of Python (e.g. ``setuptools-0.6c4-py2.4.egg``). Do NOT rename it. 2. Make it executable (e.g. ``chmod +x setuptools-0.6c4-py2.4.egg``) 3. Run it (e.g. ``./setuptools-0.6c4-py2.4.egg``). Setuptools will install itself using the matching version of Python (e.g. ``python2.4``), and will place the ``easy_install`` executable in the default location for installing Python scripts. If you want to install setuptools to somewhere other than ``site-packages`` or your default distutils installation locations for libraries and scripts, you may use EasyInstall command-line options such as ``--prefix``, ``--install-dir``, and so on. You can use ``--help`` to get a full options list, but we recommend consulting the `EasyInstall manual`_ for detailed instructions, especially `the section on custom installation locations`_. Cygwin Note ----------- If you are trying to install setuptools for the *Windows* version of Python (as opposed to the Cygwin version that lives in ``/usr/bin``), you must make sure that an appropriate executable (``python2.3``, ``python2.4``, or ``python2.5``) is on your ``PATH`` when invoking the egg. For example, doing the following at a Cygwin bash prompt will install setuptools for the *Windows* Python found at ``C:\\Python24``:: ln -s /cygdrive/c/Python24/python.exe python2.4 PATH=.:$PATH ./setuptools-0.6c4-py2.4.egg rm python2.4

4 4

Re: [Distutils] Draft of new setuptools installation instructions
by Phillip J. Eby Oct. 3, 2006

Oct. 3, 2006

At 02:40 PM 10/3/2006 -0700, Bob Ippolito wrote: >Wouldn't it be easier to just tell them to do "sh >./setuptools-0.6c4-py2.4.egg" instead of marking it executable first? I found the phrasing much more awkward that way, as it led to having to explain the idea that it's got a shell script in there. It seemed easier to just dodge the issue. But if you can come up with a phrasing that works, go for it.

2 1

Limitations of setup_requires
by Joshua Boverhof Oct. 3, 2006

Oct. 3, 2006

I included the "ZSI" package in "setup_requires" and "install_requires", but it isn't retrieved/installed before I use it via "make_generated_packages". Here is what I'm doing: class PGDistribution(_Distribution): """Indirection so that setuptools grabs "setup_requires" dependencies before calling "_make_generated_package()" """ def finalize_options (self): if _make_generated_package() is True: self.packages = find_packages() _Distribution.finalize_options(self) What I'm experiencing doesn't seem to jive with the documentation: setup_requires A string or list of strings specifying what other distributions need to be present in order for the setup script to run. So I get a big traceback because "fetch_build_egg" uses "self.__class__" to construct another Distribution instance, this time mine, and this ends up calling my "finalize_options" before I want it to... There doesn't seem to be a nice way to deal with this issue, I used a boolean in the constructor to make it work, I'd like to be able to specify a different Distribution class for my "distribution" and another for all the stuff setuptools installs. $ python setup.py installTraceback (most recent call last): File "setup.py", line 215, in <module> main() File "setup.py", line 209, in main dependency_links = [ File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/distutils/core.py", line 112, in setup _setup_distribution = dist = klass(attrs) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/setuptools-0.6c3-py2.5.egg/setuptools/ dist.py", line 219, in __init__ self.fetch_build_eggs(attrs.pop('setup_requires')) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/setuptools-0.6c3-py2.5.egg/setuptools/ dist.py", line 243, in fetch_build_eggs parse_requirements(requires), installer=self.fetch_build_egg File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/setuptools-0.6c3-py2.5.egg/pkg_resources.py", line 481, in resolve dist = best[req.key] = env.best_match(req, self, installer) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/setuptools-0.6c3-py2.5.egg/pkg_resources.py", line 717, in best_match return self.obtain(req, installer) # try and download/install File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/setuptools-0.6c3-py2.5.egg/pkg_resources.py", line 729, in obtain return installer(requirement) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/setuptools-0.6c3-py2.5.egg/setuptools/ dist.py", line 264, in fetch_build_egg dist = self.__class__({'script_args':['easy_install']}) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/site-packages/setuptools-0.6c3-py2.5.egg/setuptools/ dist.py", line 223, in __init__ _Distribution.__init__(self,attrs) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ python2.5/distutils/dist.py", line 267, in __init__ self.finalize_options() File "setup.py", line 155, in finalize_options if _make_generated_package() is True: File "setup.py", line 124, in _make_generated_package _create_generated_files(cp.items(TYPES_SEC), services=False, stubs=False, cp=cp, web2=False) File "setup.py", line 52, in _create_generated_files from ZSI.wstools.WSDLTools import WSDLReader ImportError: No module named ZSI.wstools.WSDLTools

2 5

Limitations install_requires?
by Joshua Boverhof Oct. 2, 2006

Oct. 2, 2006

I've had problems getting it to install these packages (python2.5, setuptools 0.6c3): packages with extensions fail: 4Suite -- Twisted -- already declared problem in the PackageNotes Second, if the file name of a distribution doesn't match the "package" name once installed setuptools fails to recognize it as installed. ZopeInterface --> zope.interface -- appears to build and install, but fails when setuptools tries to import it as "ZopeInterface" Or if the package installs as a sub-package of an existing package: TwistedWeb --> twisted.web -- again fails when it tries to import "TwistedWeb" I think the first two are currently impossible, but potentially I missed something with the second two? -josh

3 6

Re: [Distutils] setuptools and data files
by Phillip J. Eby Oct. 1, 2006

Oct. 1, 2006

At 09:43 PM 9/30/2006 +0200, Walter Dörwald wrote: >Hello Philip! > >I'm having trouble with using setuptools with data files. The layout of >my directory is this: > >./src >./src/CVS >./src/CVS/Root >./src/CVS/Repository >./src/CVS/Entries >./src/coverage.css >./src/pycoco.py >./CVS >./CVS/Root >./CVS/Repository >./CVS/Entries >./setup.cfg >./installer.bmp >./MANIFEST.in >./setup.py > >MANIFEST.in contains the line: >include src/coverage.css Setuptools only includes data files that are inside a *package* (which is why it's called "package_data"), or inside the .egg-info directory (metadata files), as that's the only way to ensure the files are accessible in all possible installation configurations (egg zips, egg dirs, and "traditional" installs). >My arguments to setup() look like this: > > args = dict( > name="pycoco", > version="0.1", > description="Python code coverage", > long_description="...", > author=u"Walter Doerwald", > author_email="walter(a)livinglogic.de", > url="...", > download_url="...", > license="Python", > classifiers="...", > keywords="...", > package_dir={"": "src"}, > py_modules=["pycoco"], > package_data={ > "": ["*.css"], > } > ) For this configuration, I would suggest that you move the .css file to the package's .egg-info directory, and use this expression at runtime to retrieve the contents: data = pkg_resources.get_distribution('pycoco').get_metadata('coverage.css') >However when I do an "easy_install -Z ." I get the following directory >layout: > >/var/home/coverage/pythonroot/pycoco-0.1-py2.5.egg/ >/var/home/coverage/pythonroot/pycoco-0.1-py2.5.egg/pycoco.py >/var/home/coverage/pythonroot/pycoco-0.1-py2.5.egg/pycoco.pyc >/var/home/coverage/pythonroot/pycoco-0.1-py2.5.egg/EGG-INFO >/var/home/coverage/pythonroot/pycoco-0.1-py2.5.egg/EGG-INFO/PKG-INFO >/var/home/coverage/pythonroot/pycoco-0.1-py2.5.egg/EGG-INFO/SOURCES.txt >/var/home/coverage/pythonroot/pycoco-0.1-py2.5.egg/EGG-INFO/dependency_links.txt >/var/home/coverage/pythonroot/pycoco-0.1-py2.5.egg/EGG-INFO/top_level.txt >/var/home/coverage/pythonroot/pycoco-0.1-py2.5.egg/EGG-INFO/not-zip-safe > >with no coverage.css in sight. I'm using a ~/.pydistutils.cfg, which >contains: > >[install] >install_lib = ~/pythonroot > >I've also tried including the include_package_data=True argument, moved >the CSS file out of the src directory, changes the include statement in >MANIFEST.in to "include coverage.css" and various combination thereof >always with the same result. I'm using setuptools 0.6c3. > >Am I doing something stupid? > >BTW, I've moved most of our Python packages to setuptools, and so far it >really simplifies packages handling. The only remaining problem is >setuptools+pyexe. So thanks for all your work on setuptools. > >Servus, > Walter

1 0