Mailman 3 February 2006 - Distutils-SIG

Re: [Distutils] pkg_resources.find_distributions("./")
by Phillip J. Eby 11 Feb '06

11 Feb '06

At 11:14 PM 2/10/2006 +0100, Elvelind Grandin wrote: >On 2/10/06, Phillip J. Eby <pje(a)telecommunity.com> wrote: > > There is no reliable way to tell what distribution you are in, if all you > > have is the directory name. If you have a *module* name, however, you can > > use get_provider(modulename).get_metadata('PKG-INFO') to retrieve the > > package's PKG-INFO text, which you can then use to find the distribution > > name and version. > > > >The problem is that the package might not be installed. And >get_provides needs it to be right? The module just needs to be importable.

1 0

--prefix and PYTHONPATH support added in SVN
by Phillip J. Eby 10 Feb '06

10 Feb '06

I've just checked in PYTHONPATH and --prefix support for ez_setup/easy_install that should "just work", so that the problems Joe Gregorio blogged about the other day can no longer occur. That is, at the point where he tried to use "--prefix" the current SVN version should work, with everything going smoothly from there. (I also fixed the distutils help message wart where it displays wrong usage info.) If you'd like to give it a try, you can experiment with it using: svn co http://svn.python.org/projects/sandbox/trunk/setuptools cd setuptools python setup.py install --prefix=~ This should then give you a ~/bin/easy_install command that installs stuff to ~/lib/python2.X/site-packages, as long as you have that site-packages directory on your PYTHONPATH during the initial install and for future use. And of course you can use other prefixes or --install-dir settings, as long as the target directory is on PYTHONPATH, and all the old ways of customizing installation locations should still work. And you no longer need to put any eggs on PYTHONPATH manally, ever. Anyway, I'd appreciate testers' feedback. Please feel free to be brutal in your evaluations, because at this point I'm pushing for an 0.6b1 (yes, *beta*!) release by PyCon. (By the way, for anybody wondering about the difference between ez_setup and easy_install, there really isn't one; ez_setup just downloads setuptools and runs easy_install in a bootstrap mode. So all the enhancements I just made to easy_install will be in effect for ez_setup.py too, once the next official release (0.6a10) is out.)

1 0

Re: [Distutils] pkg_resources.find_distributions("./")
by Phillip J. Eby 10 Feb '06

10 Feb '06

At 09:20 PM 2/10/2006 +0100, Elvelind Grandin wrote: >I'm using pkg_resources.find_distributions("./") to find out the name >off the distrubution in the current dir. Is there any reason this >shouldn't work? Yes, several. :) find_distributions() by default finds *all* distributions in the directory, and there is no guaranteed order to the results. Even if you pass the 'only' flag to tell it to just find distributions whose 'location' would be the same directory, you can *still* have more than one result in the case of system-packaged (--single-version-externally-managed) eggs, as they all end up in the same directory. > It works for me but apperently some others have >problems with it. There is no reliable way to tell what distribution you are in, if all you have is the directory name. If you have a *module* name, however, you can use get_provider(modulename).get_metadata('PKG-INFO') to retrieve the package's PKG-INFO text, which you can then use to find the distribution name and version.

1 0

pkg_resources.find_distributions("./")
by Elvelind Grandin 10 Feb '06

10 Feb '06

Hi. I'm using pkg_resources.find_distributions("./") to find out the name off the distrubution in the current dir. Is there any reason this shouldn't work? It works for me but apperently some others have problems with it. -- cheers elvelind grandin

1 0

New customization help message for easy_install
by Phillip J. Eby 10 Feb '06

10 Feb '06

I'm working on implementing seamless PYTHONPATH support for EasyInstall, and as I previously proposed, it's going to halt with an error message if you try to install somewhere that isn't a --site-dirs directory or on PYTHONPATH (and you're not doing a --multi-version install). Since most of the time a "naive" user will be installing to somewhere that *is* on PYTHONPATH, they probably will never see this message. But I thought it would be good to get some feedback on the proposed wording of the message. ----------------------------------------------------------------------- CONFIGURATION PROBLEM You are attempting to install a package to a directory that is not on PYTHONPATH and is not registered as supporting Python ".pth" files. Here are some of your options for correcting this: * You can choose a different installation directory, i.e., one that is on PYTHONPATH or supports .pth files. * You can add the installation directory to the PYTHONPATH environment variable. (It must then also be on PYTHONPATH whenever you run Python and want to use the package(s) you are installing.) * You can set up the installation directory to support ".pth" files, and configure EasyInstall to recognize this, by using one of the approaches described here: http://peak.telecommunity.com/EasyInstall.html#custom-installation-locations Please make the appropriate changes for your system and try again. Thank you for your patience. ----------------------------------------------------------------------- Comments, anyone?

1 0

Re: [Distutils] Some negative press for easy_install
by Phillip J. Eby 10 Feb '06

10 Feb '06

At 11:10 AM 2/9/2006 -0500, Kevin Dangoor wrote: >On 2/9/06, Ben Bangert <ben(a)groovie.org> wrote: > > It's mainly because Routes is relied on by quite a few other > > setuptools-enabled packages, so being able to easy install it was > > necessary. I didn't have a non-setuptools build mainly because I > > couldn't see how to setup a setup.py file in such a way that I could > > make both versions at once. I'm assuming I'd need two setup.py's and > > to swap them in the build depending on if it was a setuptools build > > or not. > >Could you do something like this: > >try: > from setuptools import setup >except ImportError: > from distutils.core import setup > >On your system, you'd then be able to build eggs at will. Other people >who download an sdist but don't have setuptools will just get normal >sdist-like behavior. Almost. You'll have to use MANIFEST.in or they won't be able to do bdist_rpm or certain other commands from your sdist. That is, you can't use setuptools' revision control features, since they won't have them available. Aside from that minor point, this is the approach I'd recommend to authors who are only using setuptools in order to build eggs and to upload stuff to PyPI, and aren't pointing their users to the docs. You will have to forego all of the normal conveniences of setuptools, however. Personally, however, I think that the short statement somebody else posted about "hey, I use setuptools, and if you're installing anywhere besides your system's site-packages directory you should check out this link" (to the Custom Installation Locations doc) is more than sufficient. I've been keeping setuptools in "alpha" mainly for API-change reasons, but it seems to me that the massive exposure to eggs given by TurboGears has shaken out all but the "new user hasn't read the doc and needs a custom install" problems. What impressed me most about Joe's blog post is not his installation failed, but just how close he was to actual success without even reading the documentation. So, as far as I'm concerned, as soon as it's at the point where he'd have succeeded in what he did, setuptools should qualify as beta quality. And that's just a bit of spit-and-polish away. So even though I'm not thrilled about the blog post, it's actually a pretty positive milestone in two ways: 1. It highlights how little there is left to go to get to a quality installation experience 2. It highlights how popular setuptools has already become.

6 13

/usr/lib64 site-packages (was Re: installation troubles)
by Phillip J. Eby 09 Feb '06

09 Feb '06

At 05:04 PM 2/9/2006 -0500, Karl Pietrzak wrote: >creating /usr/lib64/python2.4/site-packages/setuptools-0.6a9-py2.4.egg >Extracting setuptools-0.6a9-py2.4.egg to /usr/lib64/python2.4/site-packages >Installing easy_install script to /usr/bin > >Installed /usr/lib64/python2.4/site-packages/setuptools-0.6a9-py2.4.egg FYI, I just did a bit more research and confirmed this as a packaging problem with some 64-bit Python ports; see this thread for some background: http://mail.python.org/pipermail/distutils-sig/2005-April/004472.html Apparently, none of the Linux vendors that patch Python to install to /usr/lib64 catch all of the places that need to be patched. Some, like Fedora, however, patch it enough that I can add a workaround in setuptools to address the issue. I'm working on a candidate fix now. Are you using a Fedora-based distribution, or something else? Thanks.

1 0

Some negative press for easy_install
by Michael Twomey 09 Feb '06

09 Feb '06

Hi, Joe Gregorio has a fairly negative experience with easy_install here: http://bitworking.org/news/Please_stop_using_setuptools__at_least_exclusive… I think his points boil roughly down to these: 1. (not directly related to his first comment, but I think this might be a source of problems) easy_install isn't always called easy_install. In my case I've wound up with easy_install.py on some systems at some point in the past. Would a possible solution be to allow "python -m easy_install"? Then again I think it's pretty consistent these days. 2. No --prefix option. I think this is a case of RTFM, since it's not normally as simple as specifying a prefix. Maybe a help message which explains why --prefix isn't supported might be useful? 3. In the error message he gets it shows bog standard distutils help, so he tries --help-commands and gets an error. I think this is a definite source of frustration. 4. He tries the --install-dir option which installs the package but of course this leads to a multi-install so he can't do a plain import foo. It might be good to link to http://peak.telecommunity.com/DevCenter/EasyInstall#custom-installation-loc… for an explanation here. 5. At this point he gives up and copies the source from svn. I think in all the above there is an element of RTFM but he does have a legitimate point when it comes to the command line help, based off that alone you aren't likely to figure out the best way to use easy_install if you are doing a non-system python install. I think a link to http://peak.telecommunity.com/DevCenter/EasyInstall in the help would work wonders. cheers, Michael

6 7

Re: [Distutils] Some negative press for easy_install
by Phillip J. Eby 09 Feb '06

09 Feb '06

At 11:55 AM 2/9/2006 +0000, Paul Moore wrote: >explain this prominently somewhere: "This package uses setuptools, which >is currently in alpha status - there may be issues installing or using >the software. If you hit any problems, please report them to the >distils-sg, and thank you for helping to test setuptools". +1. This is perfect. That's why I wrote the "what your users should know" section, even though it wasn't available until recently.

1 0

Decompressing .egg files
by Giovanni Bajo 08 Feb '06

08 Feb '06

Hello, is there an easy_install option to decompress existing .egg files? I could probably run "easy_install -Z name" but that could potentially download and install another version. I'd need an option which pretty much this semantic: "if extension `name` exists and its current version is packaged as egg file, decompress it into a directory". Does it exist already? -- Giovanni Bajo

3 5