Alberto Valverde wrote:
[...]
No... which makes binary eggs unusable on Linux. I feel like there was
something else that made binary packages on a Mac unreliable, but I
can't remember. Windows binary eggs generally work fine. This is
discussed some here:
http://philikon.wordpress.com/2008/06/26/is-there-a-point-to-distributing-egg-files/
I remember reading that... Perhaps a solution could be to"freeze" the
tar.gzs too, beside the compiled eggs in case we're lucky, and hope
that a compiler + libs are there when the install script is thawed. If
the compiled egg won't cut it, then try to compile form source. I'm not
sure how to tell easy_install to download the source distributions though.
Well, it'll make eggs from your tarballs anyway. Turning it into a
build process is a bit of a nuisance... I was hoping for something that
didn't require building, but just did installation.
That said, it might work. Maybe PoachEggs (mentioned later) does what
you want in this case. Or, maybe it can be slightly modified to do what
you want (I think it might also unintentionally turn tarballs into eggs).
One nuisance is that people don't generally know how their Python was
built (UCS2 or UCS4). I was thinking about making something very
similar to eggfreezer (which I'm unlikely to do now that eggfreezer
exists ;),
You're patches are welcomed, In fact, If you want to include it inside
virtualenv I would be most happy :).
Not so much virtualenv, but it might fit in PoachEggs:
https://svn.openplans.org/svn/PoachEggs/trunk
workingenv did installation, but I abandoned that when I cleaned it up
as virtualenv, and now I'm inclined to keep them separate (though
clearly complementary).
I have thought about putting something in virtualenv to make relocating
the environment easier. There's only a few things that need to be
modified, I think. That might mitigate some of these issues.
and generating an "install" .py file that determines the
platform and downloads the appropriate platform bundle.
Hmm, this "download" is precisely what I'm trying to avoid. My main use
case is: A machine has gone down and I want to quickly put back
everything together in another machine with a backup and something that
contains *all* needed software. Sort of like an apt reposisory inside a
dvd which lets you install debian on a machine with absolutely not net
access. The "no-net" condition is just there to guarantee that all deps
will be available no matter how old and discontinued they are (which if
I think about it is rather ambitious... well, at least make it more
likely than with the current situation)
With PoachEggs I've now got it working so you can build a working
environment, create a "requirements" file that lists everything in that
working environment, download all the eggs for that into a directory,
and then later install from that directory and disallow network access.
Well, more-or-less. It's not a single-file install like eggfreezer,
but they are working toward similar goals.
The single-file install including binaries is something I would really
like for Deliverance, and specifically for lxml, but also to create a
simple installation experience for people who don't know anything about
Python build things (and maybe don't know Python).
I think that this multi-platform issue could be solved by bundling all
the different binary versions of all binary packages. However, I'm not
sure if pkg_resources could deal with the UCS2/UCS4 issue given that it
doesn't distinguish it in the platform id. Maybe by hacking in an extra
placeholder, before the .egg and after the ${platform}, that the script
uses to distinguish and then remove it before giving it to easy_install?
Though this smells like the root of the problem comes from setuptools
and should be fixed there...
If you could select the appropriate binary at installation time you
could include all of them in the bundle. It would be big, but at least
personally that would be fine for me. It would be simpler to simply
name the resulting file with a more accurate platform, but then people
don't always know the right thing to get. At least a little check in
the script itself would be helpful, so they get errors immediately
instead of confusing errors at import time. I'm not sure how to detect
UCS2/UCS4.
The root (well, *one* root) of the problem is setuptools/distutils not
getting the platform really right, but there's also all kinds of messy
backward compatibility issues there, and no backward compatibility
issues for eggfreezer. I'm not sure there aren't other issues. I'm
also not sure that there isn't a finite number of resolvable issues. So
maybe MacPorts and fink and system python on Macs are different. But
that's just 3 platforms instead of 1, it's not an infinite number. And
UCS2 Python is different from UCS4 on Linux, but that's really the one
issue I know of where Linux Pythons differ. In theory other differences
could occur, but in practice there's maybe 10 platforms instead of 3,
and that's not unreasonable.
Reading a comment on the philikon article
(http://philikon.wordpress.com/2008/06/26/is-there-a-point-to-distributing-egg-files/#comment-47),
I also notice that Enthought has done some work on this, it seems by
fixing up the binary packages at install time. This seems to be related
to an entirely different issue of the location of libraries and binary
incompatibilities, which I only slightly understand.
--
Ian Bicking : [EMAIL PROTECTED] : http://blog.ianbicking.org
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
