eggs considered harmful

[Harry George]

Re: eggs considered harmful

jjl@pobox.com (John J. Lee) writes:

Harry George <harry.g.george @boeing.comwrit es:

>jjl@pobox.com (John J. Lee) writes:

[...]

>>2. You can run your own private egg repository. IIRC, it's as simple
>>as a directory of eggs and a plain old web server with directory
>>listings turned on. You then run easy_install -f URL package_name
>>instead of easy_install package_name . The distutils-sig archives
>>will have more on this.

>>
>Again, not speaking for anyone else: With 500 OSS packages, all of
>which play by the same tarball rules, we don't have resources to
>handle eggs differently.

>
You said earlier:
>

>The rules are that a) a very few authorized downloaders obtain
>tarballs and put them in a depot and b) other users get tarballs from
>the depot and build from source.

>
Not sure how this differs significantly "from running a repository",
in the sense I use it above.
>
>
John

Significant differences:

"depot": Place(s) where tarballs can be stored, and can then be
reached via http.

"private egg repository": Tuned to the needs of Python eggs. E.g.,
not scattered over several directories or several versions.

Thus a depot of self-contained packages can handle:

1. Multiple "releases" of the depot live at the same time.

2. Packages factored into CD-sized directories (not all in one "-f" location)

3. Multiple versions of Python, without having a new egg for each.


4. Multiple target platforms. Various *NIX and MS Win and Mac systems
-- each at their own OS versions and own compiler versions. All
without having platform-specific and compiler-specific eggs.

5. Different package version selections based on compatibility with
other (non-Python) packages. E.g., to tune for GIS systems vs 3D
animation systems vs numerical analysis systems vs web server systems.

6. Refresh process which does not need to fiddle with egg-ness, or
even know about Python. Everything is a tarball.


--
Harry George
PLM Engineering Architecture

[Robert Kern]

Re: eggs considered harmful

Harry George wrote:

jjl@pobox.com (John J. Lee) writes:

>Not sure how this differs significantly "from running a repository",
>in the sense I use it above.
>>
>>
>John

>
Significant differences:
>
"depot": Place(s) where tarballs can be stored, and can then be
reached via http.
>
"private egg repository": Tuned to the needs of Python eggs. E.g.,
not scattered over several directories or several versions.

Please note that easy_install can use source tarballs, too.

Thus a depot of self-contained packages can handle:
>
1. Multiple "releases" of the depot live at the same time.

I'm not sure how this is relevant.

2. Packages factored into CD-sized directories (not all in one "-f" location)

Of course, you can specify multiple locations for easy_install to find packages.
You can store these in your ~/.pydistutils.cf g file so you never have to type
them on the command line.

3. Multiple versions of Python, without having a new egg for each.
>
4. Multiple target platforms. Various *NIX and MS Win and Mac systems
-- each at their own OS versions and own compiler versions. All
without having platform-specific and compiler-specific eggs.
>
5. Different package version selections based on compatibility with
other (non-Python) packages. E.g., to tune for GIS systems vs 3D
animation systems vs numerical analysis systems vs web server systems.
>
6. Refresh process which does not need to fiddle with egg-ness, or
even know about Python. Everything is a tarball.

And all of these are obviated by the fact that easy_install can find and build
source tarballs, too.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

[zooko@zooko.com]

Re: eggs considered harmful

Harry:

For some Free Software Python packages that I publish [1, 2, 3], I've
been trying to gain the benefits of eggs while also making the
resulting packages transparently useful to folks like you.

(You can follow along here: [4].)

One thing I've accomplished is figuring out how to install a Python
package whether it is distutils or setuptools while maintaining my
preferences for "use GNU stow" and "don't run setup code as root":
[5].

The next thing that I'm working on is bundling dependencies in source
tarball form with libraries, so that when you execute setup.py it
installs the dependency from the bundled tarball and does not attempt
to reach the Net.

So, please keep us informed about this issue. There are many benefits
of setuptools, and there are great benefits of compatibility and
standardization , and I'm hoping that we can make setuptools be more
compatible with other paradigms instead of getting into a "everybody
please use it / no everybody please don't use it" tug-of-war.

Regards,

Zooko

[1] http://cheeseshop.python.org/pypi/zfec
[2] http://cheeseshop.python.org/pypi/pyutil
[3] http://allmydata.org/trac/tahoe
[4] http://allmydata.org/trac/tahoe/ticket/15
[5] http://zooko.com/log-2007.html#d2007..._with_GNU_stow