Re: [Distutils] easy_install - some thoughts
At 09:13 AM 7/13/2005 +0200, M.-A. Lemburg wrote: > > It looks like the issue is in bdist_egg.py, write_safety_flag, where > > an ensure_directory() call is needed. There's a patch for this below, > > as well. > >Talking about "safety": shouldn't this be addressed in a standard >way, ie. signed packages ? "Zip safety" refers to whether the package can be safely installed as a zip file; i.e., whether the package is likely to work once it has been installed that way. It's not about "safety" in some security sense. >At the very least, I'd expect the downloader to compare an MD5 >checksum stored in PyPI with the one from the downloaded file. >Of course, using GPG and checking the signature based on the >public key of the author would be even better. At the moment, PyPI only stores MD5's and signatures for packages uploaded to PyPI itself, which is an extremely small minority of packages, so I haven't implemented this yet. However, easy_install runs fine on local files, so you can download and verify files before running easy_install on them. If somebody wants to contribute patches for MD5 and signing, that would certainly be nice. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install - some thoughts
On 7/12/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >But even then, things are going odd, as if I try to build an egg for
> >ctypes (which isn't zip-safe) all of the files and subdirectories in
> >the egg directory are missing the first two characters... Hmm, it
> >happens with zip-safe eggs, as well, so I don't know - maybe it's
> >related to the bdist_wininst unpacking code. Sorry, I can't debug this
> >any further.
>
> And I can't reproduce it. However, I have noticed that the format change
> for Python 2.4 includes a change to what data is in the 'cfgdata' string,
> and so I changed this line:
>
> cfg.readfp(StringIO.StringIO(f.read(cfglen)))
>
> to read:
>
> cfg.readfp(StringIO.StringIO(f.read(cfglen).split(chr(0),1)[0]))
>
> In order to ignore anything after the first NUL character in the
> cfgdata. I don't know if that was causing your two-character problem or
> not, as I can't reproduce it with Python 2.4 and the ctypes .exe for Python
> 2.4.
Looks like that fixed the problem. Thanks.
> After the first thousand levels of recursion, the time machine throws a
> RuntimeError("Paradox stablization loop limit exceeded") and kicks
> me back to the present. :)
So *that's* why Guido resists implementing tail-call optimisation! :-)
Paul
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install - some thoughts
Paul Moore wrote: > On 7/12/05, Kevin Dangoor <[EMAIL PROTECTED]> wrote: > >>On 7/12/05, Paul Moore <[EMAIL PROTECTED]> wrote: >> >>>By the way, I don't know if the sqlite web page has changed, but your >>>standard example of sqlite doesn't work for me: >> >>It may be pysqlite. > > > It's not, it's Python 2.4 :-( > > It looks like setuptools.command.easy_install is doing some ugly hacks > to read data out of the raw bdist_wininst file, in > extract_wininst_cfg, and the file format has changed in Python 2.4. > > For 2.4, it looks like the "tag" has just changed from 0x1234567A to > 0x1234567B... So just checking both values should work. I've attached > a patch. > > Still doesn't work, as I get an error about the (not-)zip-safe file: > > >>python -m easy_install -xd eggs Python\ctypes-0.9.6.win32-py2.4.exe > > Processing ctypes-0.9.6.win32-py2.4.exe > ctypes.__init__: module references __file__ > ctypes.com.register: module references __file__ > error: > c:\docume~1\gustav\locals~1\temp\easy_install-unhoeu\ctypes-0.9.6-py2.4-win32.egg.tmp\ > EGG-INFO\not-zip-safe: No such file or directory > > It looks like the issue is in bdist_egg.py, write_safety_flag, where > an ensure_directory() call is needed. There's a patch for this below, > as well. Talking about "safety": shouldn't this be addressed in a standard way, ie. signed packages ? At the very least, I'd expect the downloader to compare an MD5 checksum stored in PyPI with the one from the downloaded file. Of course, using GPG and checking the signature based on the public key of the author would be even better. After all... we don't want "easy" to spell "eval". -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 13 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install - some thoughts
At 10:11 PM 7/12/2005 +0100, Paul Moore wrote:
>On 7/12/05, Kevin Dangoor <[EMAIL PROTECTED]> wrote:
> > On 7/12/05, Paul Moore <[EMAIL PROTECTED]> wrote:
> > > By the way, I don't know if the sqlite web page has changed, but your
> > > standard example of sqlite doesn't work for me:
> >
> > It may be pysqlite.
>
>It's not, it's Python 2.4 :-(
Aha. :)
>It looks like setuptools.command.easy_install is doing some ugly hacks
>to read data out of the raw bdist_wininst file, in
Well, no uglier than the hacks that put them in there. :)
>extract_wininst_cfg, and the file format has changed in Python 2.4.
>
>For 2.4, it looks like the "tag" has just changed from 0x1234567A to
>0x1234567B... So just checking both values should work. I've attached
>a patch.
That's not the end of the difference, I'm afraid. See below.
>Still doesn't work, as I get an error about the (not-)zip-safe file:
>
> >python -m easy_install -xd eggs Python\ctypes-0.9.6.win32-py2.4.exe
>Processing ctypes-0.9.6.win32-py2.4.exe
>ctypes.__init__: module references __file__
>ctypes.com.register: module references __file__
>error:
>c:\docume~1\gustav\locals~1\temp\easy_install-unhoeu\ctypes-0.9.6-py2.4-win32.egg.tmp\
>EGG-INFO\not-zip-safe: No such file or directory
>
>It looks like the issue is in bdist_egg.py, write_safety_flag, where
>an ensure_directory() call is needed. There's a patch for this below,
>as well.
Actually, the problem is that install_exe() isn't creating the EGG-INFO
directory in the first place, but your fix is okay as a workaround. (The
difference is that if converting from exe->egg ever needs any other
metadata files, the problem could recur; but by creating EGG-INFO up front
in install_exe(), creating other metadata files should be fine.)
>But even then, things are going odd, as if I try to build an egg for
>ctypes (which isn't zip-safe) all of the files and subdirectories in
>the egg directory are missing the first two characters... Hmm, it
>happens with zip-safe eggs, as well, so I don't know - maybe it's
>related to the bdist_wininst unpacking code. Sorry, I can't debug this
>any further.
And I can't reproduce it. However, I have noticed that the format change
for Python 2.4 includes a change to what data is in the 'cfgdata' string,
and so I changed this line:
cfg.readfp(StringIO.StringIO(f.read(cfglen)))
to read:
cfg.readfp(StringIO.StringIO(f.read(cfglen).split(chr(0),1)[0]))
In order to ignore anything after the first NUL character in the
cfgdata. I don't know if that was causing your two-character problem or
not, as I can't reproduce it with Python 2.4 and the ctypes .exe for Python
2.4.
>BTW, it would be useful to have some type of debug flag which left the
>temporary directory around for debugging...
See the --build-dir/-b option, which is what I used to do my own
investigation of the above. The time machine strikes again! :)
Unfortunately, the time machine won't let me fix bugs because it would
create an infinite time loop; if I only know about the bug because you
report it, then going back to fix the bug would mean you wouldn't report
it, and so on. After the first thousand levels of recursion, the time
machine throws a RuntimeError("Paradox stablization loop limit exceeded")
and kicks me back to the present. :)
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install - some thoughts
At 08:41 PM 7/12/2005 +0100, Paul Moore wrote: >However, if setuptools is installed as an egg, python -m easy_install >doesn't work (and putting the egg on PYTHONPATH, or even renaming it >as .zip didn't help - this may be a bug in Python's -m support...) Darnit. I forgot about this issue. You can't run a script-in-a-zip with 'python -m', which means that I need to make setuptools itself be "not zip safe". Which sucks, since I'd like it to be a poster child for zip safety, but oh well. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install - some thoughts
At 07:37 PM 7/12/2005 +0100, Paul Moore wrote: >This is with setuptools-0.5a9, btw, I haven't had time to download the >new version yet (there's no Windows installer, so I'll have to use the >egg, which shouldn't be hard but I'd rather not compound the issues by >using a mis-installed package :-)) After a9 I got rid of the Windows installer, as I forgot that it was installing an "unmanaged" version of setuptools. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install - some thoughts
On 7/12/05, Kevin Dangoor <[EMAIL PROTECTED]> wrote:
> On 7/12/05, Paul Moore <[EMAIL PROTECTED]> wrote:
> > By the way, I don't know if the sqlite web page has changed, but your
> > standard example of sqlite doesn't work for me:
>
> It may be pysqlite.
It's not, it's Python 2.4 :-(
It looks like setuptools.command.easy_install is doing some ugly hacks
to read data out of the raw bdist_wininst file, in
extract_wininst_cfg, and the file format has changed in Python 2.4.
For 2.4, it looks like the "tag" has just changed from 0x1234567A to
0x1234567B... So just checking both values should work. I've attached
a patch.
Still doesn't work, as I get an error about the (not-)zip-safe file:
>python -m easy_install -xd eggs Python\ctypes-0.9.6.win32-py2.4.exe
Processing ctypes-0.9.6.win32-py2.4.exe
ctypes.__init__: module references __file__
ctypes.com.register: module references __file__
error:
c:\docume~1\gustav\locals~1\temp\easy_install-unhoeu\ctypes-0.9.6-py2.4-win32.egg.tmp\
EGG-INFO\not-zip-safe: No such file or directory
It looks like the issue is in bdist_egg.py, write_safety_flag, where
an ensure_directory() call is needed. There's a patch for this below,
as well.
But even then, things are going odd, as if I try to build an egg for
ctypes (which isn't zip-safe) all of the files and subdirectories in
the egg directory are missing the first two characters... Hmm, it
happens with zip-safe eggs, as well, so I don't know - maybe it's
related to the bdist_wininst unpacking code. Sorry, I can't debug this
any further.
BTW, it would be useful to have some type of debug flag which left the
temporary directory around for debugging...
Paul.
--- setuptools\command\easy_install.py.orig 2005-07-10 22:26:46.0
+0100
+++ setuptools\command\easy_install.py 2005-07-12 21:30:04.71875 +0100
@@ -877,7 +877,7 @@
import struct, StringIO, ConfigParser
tag, cfglen, bmlen = struct.unpack("0x1234567A:
+if tag<>0x1234567A and tag<>0x1234567B:
return None # not a valid tag
f.seek(prepended-(12+cfglen+bmlen))
--- \Apps\Python24\Lib\site-packages\setuptools\command\bdist_egg.py.orig
2005-07-10
23:32:28.0 +0100
+++ \Apps\Python24\Lib\site-packages\setuptools\command\bdist_egg.py
2005-07-12
21:55:35.78125 +0100
@@ -8,7 +8,7 @@
from distutils.dir_util import remove_tree, mkpath
from distutils.sysconfig import get_python_version, get_python_lib
from distutils import log
-from pkg_resources import get_platform, Distribution
+from pkg_resources import get_platform, Distribution, ensure_directory
from types import CodeType
def write_stub(resource, pyfile):
@@ -315,7 +315,9 @@
def write_safety_flag(egg_dir, safe):
# Write a zip safety flag file
flag = safe and 'zip-safe' or 'not-zip-safe'
-open(os.path.join(egg_dir,'EGG-INFO',flag),'w').close()
+filename = os.path.join(egg_dir,'EGG-INFO',flag)
+ensure_directory(filename)
+open(filename, 'w').close()
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install - some thoughts
On 7/12/05, Kevin Dangoor <[EMAIL PROTECTED]> wrote: > easy_install -U setuptools > > is the easiest way to upgrade. And, once you have the new version, you > will be able to do python -m easy_install -U setuptools to keep up to > date. That conflicts with a bdist_wininst installation. Shouldn't be too hard to sort out, but there's a little bit of a chicken and egg issue here :-) Actually, ez_setup.py works fine on Windows - so that may well be a better option for Windows users with network access. However, if setuptools is installed as an egg, python -m easy_install doesn't work (and putting the egg on PYTHONPATH, or even renaming it as .zip didn't help - this may be a bug in Python's -m support...) Paul. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install - some thoughts
On 7/12/05, Paul Moore <[EMAIL PROTECTED]> wrote: > By the way, I don't know if the sqlite web page has changed, but your > standard example of sqlite doesn't work for me: It may be pysqlite. > This is with setuptools-0.5a9, btw, I haven't had time to download the > new version yet (there's no Windows installer, so I'll have to use the > egg, which shouldn't be hard but I'd rather not compound the issues by > using a mis-installed package :-)) easy_install -U setuptools is the easiest way to upgrade. And, once you have the new version, you will be able to do python -m easy_install -U setuptools to keep up to date. Kevin ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install - some thoughts
On 7/12/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 11:11 AM 7/12/2005 +0100, Paul Moore wrote:
> >Quick question, is there a "convert but don't install yet" option? So
> >I get an egg on my PC, but not in site-packages.
>
> Yes, it's called --install-dir, and you set it to the directory where you'd
> like it to dump the egg. :) If you don't want script wrappers in that
> directory too, use --exclude-scripts as well. So, "easy_install -xd
> somedir pysqlite" would dump the pysqlite egg in "somedir".
Neat, thanks.
By the way, I don't know if the sqlite web page has changed, but your
standard example of sqlite doesn't work for me:
>\Apps\Python24\Scripts\easy_install.py -xd test sqlite
Searching for sqlite
Reading http://www.python.org/pypi/sqlite/
Reading http://pysqlite.org/
No local packages or download links found for sqlite
error: Could not find distribution for Requirement('sqlite', [], ())
I tried a few others - cx_Oracle, ctypes, kinterbasdb,
python-dateutil, and they didn't work either. PIL *nearly* did - it
found the PIL 1.1.5 Windows installer for Python 2.4, but it then
failed with
error:
c:\docume~1\gustav\locals~1\temp\easy_install-k1vu-u\PIL-1.1.5.win32-py2.4.exe
is not a valid distutils Windows .exe
which is probably wrong, as the URL was correct and the file is a
Python installer, but I can't diagnose much further as the temp file
was deleted - could it be binary/text file issues? Actually, if I
download the file manually and do "easy_install.py -xd test
PIL-1.1.5.win32-py2.4.exe" I still get the same error, so it's deeper
than that...
I can't think of much more I can do to diagnose this for you, but let
me know if there's anything you'd like me to try.
This is with setuptools-0.5a9, btw, I haven't had time to download the
new version yet (there's no Windows installer, so I'll have to use the
egg, which shouldn't be hard but I'd rather not compound the issues by
using a mis-installed package :-))
Paul..
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install - some thoughts
At 11:11 AM 7/12/2005 +0100, Paul Moore wrote: >Quick question, is there a "convert but don't install yet" option? So >I get an egg on my PC, but not in site-packages. Yes, it's called --install-dir, and you set it to the directory where you'd like it to dump the egg. :) If you don't want script wrappers in that directory too, use --exclude-scripts as well. So, "easy_install -xd somedir pysqlite" would dump the pysqlite egg in "somedir". Or, if the .exe is on your machine already then "easy_install -xd somedir somepackage.win32.exe" will do the trick. (Note that EasyInstall only manipulates .pth files when installing to site-packages, so this should do exactly what you want.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install - some thoughts
On 7/12/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 10:32 PM 7/11/2005 +0100, Paul Moore wrote: > >2. It would be useful if the -f option worked with a file: URL (or > >better still, a simple directory name), to handle local > >repositories. > > A good idea, which I've been thinking about. I'll add it in the next > release, such that if an argument to -f is not a URL, it gets checked for > being an existing directory. If it's a directory, I'll scan the contents > as if they were links on a webpage. If it's not an existing directory, > I'll print a warning (since errors should not pass silently) and proceed. Agreed. Thanks. > >3. I still dislike the fact that I can't get a listing of installed > >eggs. > > I suggest writing a simple script using pkg_resources.find_distributions(), > and perhaps adding some documentation and contributing it to setuptools. :) > > > >And uninstalling by deletion isn't good, IMHO. > > So write a pkg_delete script and contribute it, too. See my earlier message. I will do so. > I've got no objection to these other tools, they just haven't been my top > priority and aren't likely to be for a while. I'd like to focus on the core > engine/API, in such a way that other people can easily write these > sorts of management tools around it. Great. I'll see what I can do to contribute in that area. > >4. --dry-run doesn't work as expected: [...] > Sadly, this is about what *I* expect, [...] > I've been making the assumption that it's more useful to have a dry run > that tells you most of what it does before dying, than to have no dry-run > capability at all. My reason for using --dry-run was because while I'm happy to do the build steps in a work area, I don't want to do the install until I see what will happen (just in case I've got something wrong!) So for me, dry-run capability is only really crucial for the install step. I'd actually done all of the previous steps (the build bits) for real in any case, so the dry run did nothing before failing... But I see what you mean, it's standard distutils machinery so you haven't got much freedom to change it, and ultimately when enough things aren't done, the remaining steps are meaningless anyway. > >A nice to have feature would be the ability for easy_install to pick > >apart a bdist_wininst installer and build an egg from it. > > Then I guess it's a good thing I implemented it already. :) Cool! Now give back the time machine... > Try running EasyInstall on a win32.exe file, and you'll find that it > actually does a pretty good job of turning it into an egg. If you were to run > "easy_install pysqlite", for example, (assuming you could get past your > firewall) you'd notice that it finds and downloads the bdist_wininst > installer for PySQLite, converts it to an egg, and then installs it. This > feature is only obscurely referenced in the docs and changelog, so I don't > really blame you for missing it. :) Quick question, is there a "convert but don't install yet" option? So I get an egg on my PC, but not in site-packages. > >On a related note, had you thought of having EasyInstall put eggs in > >a specific subdirectory? Something like site-packages/eggs? As you're > >using .pth files, this wouldn't be any harder to manage, would it? > > Yes, it would, actually, especially for non-system installs, as Michael > Hoffman was asking about here recently. The main reason for putting eggs > in sys.path directories, however, is to support automatic discovery and > adding them to sys.path at *runtime*, dynamically. I also wanted to take > advantage of certain properties of sys.path, like the fact that Python's > start script has its directory added to sys.path. This then makes eggs in > the script directory easily discoverable. > > In fact, if you set an --install-dir with EasyInstall, and set the > --always-copy flag, then your installation directory is an "application > directory". Scripts and eggs are both copied there, including all eggs > needed to run the application. Now you can just ship that directory and it > can be used anywhere you have Python and setuptools installed. > > Anyway, I think putting eggs in directories on sys.path is a natural > extension of the sys.path concept, that seems to me to avoid the mental > overhead of having a separate search path that works differently. > > > >I can see a use case for a "combination" egg. One which packages > >together a group of packages. For example, if I want a standard set > >of packages installed on all machines, so that users can assume they > >are present when writing one-off scripts. If I could package > >*existing* eggs up into a combination site-std.egg > > This is called a "basket" (as in putting all your eggs in one basket!), and > it's actually already supported, I told you - give back that time machine! :-) Seriously, I'm getting more and more impressed... > Anyway, if you end up with something nice and want to contribu
Re: [Distutils] easy_install - some thoughts
At 10:32 PM 7/11/2005 +0100, Paul Moore wrote: >1. It would be much better if easy_install was usable via python -m, >either as well as or instead of the existing easy_install.py >script. I actually goofed in removing this; I'll put it back in the next release. >2. It would be useful if the -f option worked with a file: URL (or >better still, a simple directory name), to handle local >repositories. A good idea, which I've been thinking about. I'll add it in the next release, such that if an argument to -f is not a URL, it gets checked for being an existing directory. If it's a directory, I'll scan the contents as if they were links on a webpage. If it's not an existing directory, I'll print a warning (since errors should not pass silently) and proceed. >3. I still dislike the fact that I can't get a listing of installed >eggs. I suggest writing a simple script using pkg_resources.find_distributions(), and perhaps adding some documentation and contributing it to setuptools. :) >And uninstalling by deletion isn't good, IMHO. I am >*strongly* averse to using raw file operations (delete) on files >in Python\lib\site-packages. Elsewhere, fine, but I view the >Python standard library as a "managed" area, and management tools >should exist for it. That's the key benefit to me of bdist_wininst, >and I don't see eggs providing it. So write a pkg_delete script and contribute it, too. I've got no objection to these other tools, they just haven't been my top priority and aren't likely to be for a while. I'd like to focus on the core engine/API, in such a way that other people can easily write these sorts of management tools around it. >4. --dry-run doesn't work as expected: > > >\Apps\Python24\Scripts\easy_install.py --dry-run > dist/alarm-1.0-py2.4-win32.egg > >Processing alarm-1.0-py2.4-win32.egg >Copying alarm-1.0-py2.4-win32.egg to C:\Apps\Python24\Lib\site-packages >zipimport.ZipImportError: not a Zip file Sadly, this is about what *I* expect, because most distutils commands can only get so far into a --dry-run before some step depends on the nonexistent output of the preceding step. I've been making the assumption that it's more useful to have a dry run that tells you most of what it does before dying, than to have no dry-run capability at all. It's possible that I could make later steps say, "I'm in dry run mode and I don't know what the heck to do here", but I'm really not sure how I'd start. If you or someone else has patches, I'll be happy to look at incorporating them. Again, my focus for the next few releases is going to be on hardening pkg_resources to make it more robust and to have a more usable API. >A nice to have feature would be the ability for easy_install to pick >apart a bdist_wininst installer and build an egg from it. Then I guess it's a good thing I implemented it already. :) Try running EasyInstall on a win32.exe file, and you'll find that it actually does a pretty good job of turning it into an egg. If you were to run "easy_install pysqlite", for example, (assuming you could get past your firewall) you'd notice that it finds and downloads the bdist_wininst installer for PySQLite, converts it to an egg, and then installs it. This feature is only obscurely referenced in the docs and changelog, so I don't really blame you for missing it. :) >On a related note, had you thought of having EasyInstall put eggs in >a specific subdirectory? Something like site-packages/eggs? As you're >using .pth files, this wouldn't be any harder to manage, would it? Yes, it would, actually, especially for non-system installs, as Michael Hoffman was asking about here recently. The main reason for putting eggs in sys.path directories, however, is to support automatic discovery and adding them to sys.path at *runtime*, dynamically. I also wanted to take advantage of certain properties of sys.path, like the fact that Python's start script has its directory added to sys.path. This then makes eggs in the script directory easily discoverable. In fact, if you set an --install-dir with EasyInstall, and set the --always-copy flag, then your installation directory is an "application directory". Scripts and eggs are both copied there, including all eggs needed to run the application. Now you can just ship that directory and it can be used anywhere you have Python and setuptools installed. Anyway, I think putting eggs in directories on sys.path is a natural extension of the sys.path concept, that seems to me to avoid the mental overhead of having a separate search path that works differently. >I can see a use case for a "combination" egg. One which packages >together a group of packages. For example, if I want a standard set >of packages installed on all machines, so that users can assume they >are present when writing one-off scripts. If I could package >*existing* eggs up into a combination site-std.egg Th
[Distutils] easy_install - some thoughts
I just built a couple of eggs, for interest, experimentation, and generally "having a go" with setuptools. A couple of things struck me about the end-user experience with easy_install: 1. It would be much better if easy_install was usable via python -m, either as well as or instead of the existing easy_install.py script. On Windows, C:\Python24\Scripts is not normally on %PATH%, so easy_install isn't directly available after installing setuptools, without an additional step. 2. It would be useful if the -f option worked with a file: URL (or better still, a simple directory name), to handle local repositories. 3. I still dislike the fact that I can't get a listing of installed eggs. And uninstalling by deletion isn't good, IMHO. I am *strongly* averse to using raw file operations (delete) on files in Python\lib\site-packages. Elsewhere, fine, but I view the Python standard library as a "managed" area, and management tools should exist for it. That's the key benefit to me of bdist_wininst, and I don't see eggs providing it. 4. --dry-run doesn't work as expected: >\Apps\Python24\Scripts\easy_install.py --dry-run dist/alarm-1.0-py2.4-win32.egg Processing alarm-1.0-py2.4-win32.egg Copying alarm-1.0-py2.4-win32.egg to C:\Apps\Python24\Lib\site-packages Traceback (most recent call last): File "C:\Apps\Python24\Scripts\easy_install.py", line 18, in ? main(sys.argv[1:]) File "C:\Apps\Python24\Lib\site-packages\setuptools\command\easy_install.py", line 987, in main setup(script_args = ['-q','easy_install', '-v']+argv, **kw) File "C:\Apps\Python24\Lib\site-packages\setuptools\__init__.py", line 51, in setup return distutils.core.setup(**attrs) File "C:\Apps\Python24\lib\distutils\core.py", line 149, in setup dist.run_commands() File "C:\Apps\Python24\Lib\site-packages\setuptools\dist.py", line 419, in run _commands self.run_command(cmd) File "C:\Apps\Python24\lib\distutils\dist.py", line 966, in run_command cmd_obj.run() File "C:\Apps\Python24\Lib\site-packages\setuptools\command\easy_install.py", line 222, in run self.easy_install(spec) File "C:\Apps\Python24\Lib\site-packages\setuptools\command\easy_install.py", line 260, in easy_install return self.install_item(None, spec, tmpdir, True) File "C:\Apps\Python24\Lib\site-packages\setuptools\command\easy_install.py", line 294, in install_item dists = self.install_eggs(download, tmpdir) File "C:\Apps\Python24\Lib\site-packages\setuptools\command\easy_install.py", line 414, in install_eggs return [self.install_egg(dist_filename, tmpdir)] File "C:\Apps\Python24\Lib\site-packages\setuptools\command\easy_install.py", line 491, in install_egg return self.egg_distribution(destination) File "C:\Apps\Python24\Lib\site-packages\setuptools\command\easy_install.py", line 456, in egg_distribution metadata = EggMetadata(zipimport.zipimporter(egg_path)) zipimport.ZipImportError: not a Zip file Don't get me wrong - eggs are definitely going in the right direction. But there's still a way to go (for me, at least) yet. Some more unfocused and rambling thoughts: A nice to have feature would be the ability for easy_install to pick apart a bdist_wininst installer and build an egg from it. This would enormously help Windows users who don't have a compiler, but do want to use eggs - in my view, it's fairly "all or nothing" choice. You *don't* want to have part of your installation managed via bdist_wininst installers (more accurately, by the OS native package management), and another part by EasyInstall. On a related note, had you thought of having EasyInstall put eggs in a specific subdirectory? Something like site-packages/eggs? As you're using .pth files, this wouldn't be any harder to manage, would it? I can see a use case for a "combination" egg. One which packages together a group of packages. For example, if I want a standard set of packages installed on all machines, so that users can assume they are present when writing one-off scripts. If I could package *existing* eggs up into a combination site-std.egg (this is a pure aggregation operation, and should not require the ability to build extensions) then I could install the one egg across the site (and version that independently of the individual packages). There's a similar facility available in TCL's "starkits" (see http://www.equi4.com/starkit.html) - which are well worth a look for ideas, as they are fairly similar in concept to eggs. Paul. -- Once the game is over, the King and the pawn go back in the same box. -- Italian Proverb ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
