When Python *Eggs* better than Python *distutils*?? What's Eggs?

[seberino]

I have been using distuils for a while and was wondering when
Python Eggs (new project) is better?

So basically Python Eggs precompiles and compresses
binaries for you so you just have to load it to run
your app?

Chris

[Ben Finney]

"se******@spawar.navy.mil" <se******@spawar.navy.mil> writes:

I have been using distuils for a while and was wondering when Python
Eggs (new project) is better?

Python Eggs, and the 'setuptools' package, are still new, so they're
not yet a core part of Python.

"The primary benefits of Python Eggs are:

* They enable tools like the "Easy Install" Python package manager
(NEW!)

* They are a "zero installation" format for a Python package; no
build or install step is required, just put them on PYTHONPATH
or sys.path and use them

* They can include package metadata, such as the other eggs they
depend on

* They allow "namespace packages" (packages that just contain
other packages) to be split into separate distributions
(e.g. zope.*, twisted.*, peak.* packages can be distributed as
separate eggs, unlike normal packages which must always be
placed under the same parent directory. This allows what are now
huge monolithic packages to be distributed as separate
components.)

* They allow applications or libraries to specify the needed
version of a library, so that you can
e.g. require("Twisted-Internet>=2.0") before doing an import
twisted.internet.

* They're a great format for distributing extensions or plugins to
extensible applications and frameworks (such as Trac, which uses
eggs for plugins as of 0.9b1), because the egg runtime provides
simple APIs to locate eggs and find their advertised entry
points (similar to Eclipse's "extension point" concept).

There are also other benefits that may come from having a
standardized format, similar to the benefits of Java's "jar"
format."

<URL:http://peak.telecommunity.com/DevCenter/PythonEggs>

--
\ "There was a point to this story, but it has temporarily |
`\ escaped the chronicler's mind." -- Douglas Adams |
_o__) |
Ben Finney <http://www.benfinney.id.au/>

[Xavier Morel]

se******@spawar.navy.mil wrote:

So basically Python Eggs precompiles and compresses
binaries for you so you just have to load it to run
your app?

Nah, Eggs is a packaging system, what you don't have to do is
compile/configure, because the packaging does that for you. It also
handles things like pre-required packages (the packages that this
package uses), even though that doesn't always work atm.

If you ever used a debian-based linux system, think of Eggs as a
Python-specific apt-get.

The most advanced kind of language-specific installer atm is the Ruby
Gems packaging and distribution system (http://docs.rubygems.org/), go
check it for more insight of what Eggs wants to be (and I hope it'll
evolve to be as good as gems) (and the install software should be named
eggs or hatch, not easy_install, ugly).

[Colin J. Williams]

Xavier Morel wrote:

se******@spawar.navy.mil wrote:

So basically Python Eggs precompiles and compresses
binaries for you so you just have to load it to run
your app?

Nah, Eggs is a packaging system, what you don't have to do is
compile/configure, because the packaging does that for you. It also
handles things like pre-required packages (the packages that this
package uses), even though that doesn't always work atm.

If you ever used a debian-based linux system, think of Eggs as a
Python-specific apt-get.

The most advanced kind of language-specific installer atm is the Ruby
Gems packaging and distribution system (http://docs.rubygems.org/), go
check it for more insight of what Eggs wants to be (and I hope it'll
evolve to be as good as gems) (and the install software should be named
eggs or hatch, not easy_install, ugly).

Currently, most packages are installed into the site-packages directory.

Does Eggs facilitate this?

Colin W.

[Paul Boddie]

Xavier Morel wrote:

If you ever used a debian-based linux system, think of Eggs as a
Python-specific apt-get.

The most advanced kind of language-specific installer atm is the Ruby
Gems packaging and distribution system (http://docs.rubygems.org/), go
check it for more insight of what Eggs wants to be (and I hope it'll
evolve to be as good as gems) (and the install software should be named
eggs or hatch, not easy_install, ugly).

Could anyone enlighten me/us as to why the Smart Package Manager [1]
(written in Python, presented at EuroPython this year) isn't being more
closely investigated as part of a suitable solution?

Paul

[1] http://smartpm.org/

[Maurice LING]

Xavier Morel wrote:

se******@spawar.navy.mil wrote:

So basically Python Eggs precompiles and compresses
binaries for you so you just have to load it to run
your app?

Nah, Eggs is a packaging system, what you don't have to do is
compile/configure, because the packaging does that for you. It also
handles things like pre-required packages (the packages that this
package uses), even though that doesn't always work atm.

If you ever used a debian-based linux system, think of Eggs as a
Python-specific apt-get.

The most advanced kind of language-specific installer atm is the Ruby
Gems packaging and distribution system (http://docs.rubygems.org/), go
check it for more insight of what Eggs wants to be (and I hope it'll
evolve to be as good as gems) (and the install software should be named
eggs or hatch, not easy_install, ugly).

I think this is one very specific area that one BIG community-wide
concerted effort is better than a few smaller ones. Is there any chance
of better coordination in this area?

maurice

[dangoor]

setuptools discussion has been ongoing on distutils-sig for months.
Though the vast majority of the work has been done by Phillip Eby,
there has been input from quite a few people along the way.

I haven't seen any other related effort that comes anywhere close to
setuptools. What do you envision as better coordination?

Kevin

[Phillip J. Eby]

Paul Boddie wrote:

Could anyone enlighten me/us as to why the Smart Package Manager [1]
(written in Python, presented at EuroPython this year) isn't being more
closely investigated as part of a suitable solution?

More closely investigated by whom, as a solution for what? Surely
there is someone somewhere investigating it as a solution for
something, so your presupposition that it isn't would seem to imply
that you have some more specific person(s) and solution(s) in mind. :)

If you are speaking with respect to setuptools, I would just point out
that it is intended to be packaging-system neutral. While the
easy_install package manager will work on most platforms supported by
Python, it's intended only for tasks that cannot be accomplished using
the local package management system. So, I've definitely "closely
investigated" package management tools "as part of a suitable
solution," and have recently added features to make eggs work better
with package management tools. This consideration, however, does not
extend to providing any special integration with any *particular*
package management tools, especially since some systems (e.g. Windows)
have little or no such support, and a common usage environment for
Python web applications at least (shared hosting providers) offer no
way to *use* the system package manager at all.

That having been said, a few quick glances at Smart's source code show
me that Smart itself could perhaps benefit from eggs, for example to
handle plugins for channels and distribution types. Its hook system,
for example, could be handled in a decentralized way. Also, in theory
at least, it looks like Smart could be extended to recognize eggs and
manage them as well, but I haven't looked deeply into any of these
questions since they're not in scope for my efforts at this time.
However, it would certainly appear that *someone* could investigate
making Smart a bigger part of some "suitable solution" for something.
:)

[Phillip J. Eby]

se******@spawar.navy.mil wrote:

I have been using distuils for a while and was wondering when
Python Eggs (new project) is better?
If you have a relatively simple setup script, don't need to upload your
package to PyPI, and don't include any files other than .py files and C
extensions in your distribution, you won't benefit much from switching
to setuptools.

If you have a lot of non-code files, setuptools will let you get rid of
MANIFEST hassles and data file installation issues. A fairly complete
list of setuptools features can be found here:

http://cheeseshop.python.org/pypi/setuptools

Most of these are just conveniences for the developer, that get rid of
a lot of the repetitious code you have to put in setup.py, especially
if you are doing anything that the distutils doesn't handle
automatically.

However, the "killer app" feature of setuptools is that it lets you
distribute a project that depends on other software available via PyPI.
Instead of having to bundle the other project inside yours, or tell
users to manually download and install the dependencies. If you use
setuptools, then you can take advantage of automatic dependency
download and installation, making it easier for you as a developer to
reuse existing open source Python code. This is the real reason
setuptools and eggs and easy_install exist: to allow Python developers
to reuse code without bundling or manual dependency management --
regardless of platform. (i.e., without them having to support rpm,
deb, msi, dpkg, pkgsrc, and all the other nine jillion packaging
systems out there).

So basically Python Eggs precompiles and compresses
binaries for you so you just have to load it to run
your app?

Python eggs are a way of bundling additional information with a Python
project, that allows its dependencies to be checked and satisfied at
runtime, as well as allowing projects to provide plugins for other
projects. There are several formats for this, but the '.egg' zipfile
format is a convenient one for *distributing* projects. Whether you
keep them compressed or not when you install them is partly a matter of
whether the project is able to be used in compressed form, and whether
you want to be able to use certain documentation or debugging tools
that don't always work with zip files.

This .egg format is created by the "bdist_egg" command, which is
basically similar to bdist_wininst or bdist_rpm, in that it creates a
file you can then upload to PyPI or otherwise distribute. The main
difference between .egg and win32.exe or .rpm is that .egg files can be
put directly on sys.path and used, while the other formats cannot.

[Paul Boddie]

Phillip J. Eby wrote:

Paul Boddie wrote:

Could anyone enlighten me/us as to why the Smart Package Manager [1]
(written in Python, presented at EuroPython this year) isn't being more
closely investigated as part of a suitable solution?
More closely investigated by whom, as a solution for what? Surely
there is someone somewhere investigating it as a solution for
something, so your presupposition that it isn't would seem to imply
that you have some more specific person(s) and solution(s) in mind. :)

Well, it seemed quite odd to me when one of the leading package
management experts gives a talk at a Python conference about the
package management tool that he's developing (having already
successfully developed one or more of the better existing solutions),
and yet no-one in the vocal, blogging Python community seems to have
heard of the tool in question. One would have thought that this would
have been fertile ground for collaboration.

Not that a lack of awareness of wider trends and technologies isn't
unusual: a brief EuroPython corridor discussion of groupware standards
elicited the astonishing response from one participant that such
standards were designed for centralized server configurations when one
clearly gets the opposite impression when reading the standards
documents and actually using the related technologies in practice. (The
lack of awareness of things like Kontact and KMail - ie. anything other
than Microsoft Outlook plus Exchange - seems pretty widespread even
amongst people who supposedly "know Linux and have considered Novell
Evolution", however, so it isn't really that fair to single other
participants out over that particular point.)
However, it would certainly appear that *someone* could investigate
making Smart a bigger part of some "suitable solution" for something.
:)

Indeed. I considered looking into just that, but we all only have time
for so much. ;-)

Paul