Just wanted to say, you have done it again my man. This is *exactly* what I was looking for: in combination with virtualenv, I can now bootstrap my entire build environment in one command line. AWESOME!!!! You saved me a ton of work.

Thanks again, I shall enjoy using this immensely…

Jamie

I was just thinking about this the other day. I wanted to file a bug report against easy_install for going half way through my install and then telling me that a package conflicts with another egg.

Thats something else I don’t undrestand, how can they conflict. They have already hacked it till no end with all these .pth files so there is no way I can import to different versions at the same time. Or maybe thats why they conflict.

Another thing I could not figure out, was how come the dependencies begin from the last item in the list working upwards, is it just to inconvenience us???

Neways back to PIP, thanks for the great package. I was not sure if it is 2.6 compatible, so I installed easy_install. Not to be a hypocrite, but as soon as I can see its py26 capable Im on.

–
Hatem Nassrat

There is a name problem, though, because I’m pretty sure it has to be a two-level command, like “pyinstall install Foo”, “pyinstall bundle Bar”, etc, but “pyinstall install” reads horribly.

I’ve programmed Python for a long time, but one nice thing I noticed during a brief Ruby foray is that Ruby’s install tool is called gem, and it installs gems, which have the file extension “.gem”. I never had trouble remembering the name of the tool.

Then to install the installer, the package can be called python-egg, packaged as a regular tarball for normal setup.py install action, and provided as rpm, deb, etc. - instead of the unorthodox download of some ez_setup. Consistency. The fewer names the better!

Re: uninstallation, sure, at some point. Each package has a record of installed files, so it’s fairly easy.

I haven’t figured out how to do interactive stuff. I guess I just need a –no-interactive option or something. People will often want to drive this from scripts, so interactive things (like warning about global installation) is likely to be problematic. (There already is at least one prompt, though.)

David: this installs packages as eggs, bug as flat (not multi-version) eggs, so sys.path doesn’t get larger. This was a feature already in setuptools, setup.py install –single-version-externally-managed.

Noah: requirement files, when written sufficiently strictly, guarantee you get what you wanted. You can stuff those files into version control too (which I wouldn’t advise for the big pybundle zip files). So there’s actually kind of two solutions to that problem in pyinstall.

$ /Library/Python/2.5/site-packages/pyinstall-0.1-py2.5.egg/EGG-INFO/scripts$ ls -l
total 184
-rwxr-xr-x 1 feamcor admin 91001 Sep 24 16:18 pyinstall.py

Edit the file pyinstall.py and merge the fix below:

if getattr(sys, ‘real_prefix’, None):
## FIXME: is build/ a good name?
base_prefix = os.path.join(sys.prefix, ‘build’)
base_src_prefix = os.path.join(sys.prefix, ’src’)
else:
## FIXME: this isn’t a very good default
base_prefix = os.path.join(os.getcwd(), ‘build’)
# FEAMCOR - wrong variable is being used here. Script fails to init on Mac OS X
#base_prefix = os.path.join(os.getcwd(), ’src’)
base_src_prefix = os.path.join(os.getcwd(), ’src’)

Anyway, I loved the bundle idea!