[Distutils] Simpler Python package management: the "egg" command

[Luís Bruno]

'lo there!

Bjørn Stabell:
> * Find available eggs for a particular topic online
> * Get more information about an egg
> * Install an egg (and its dependencies)
> * See which eggs are installed
> * Upgrade some or all outdated eggs
> * Remove/uninstall an egg
> * Create an egg
> * Find eggs that are plugins for some framework online

Having a checklist of use cases is useful, as others can add to it (or
shoot items down). Thanks.


> egg                     - list out a help of commands
> egg search      - search for eggs (aliases: find/list)
> egg info                - show info for egg (aliases: show/details)
> egg install     - install named eggs
> egg uninstall           - uninstall eggs (aliases: remove/purge/delete)
> [...]
> egg list installed sql               - list all installed eggs having sql in their name
> egg search installed sql     - list all installed eggs mentioning sql anywhere [...]
> egg list oudated installed   - list all outdated installed eggs
> egg list oudated active      - list all outdated and active (and installed) eggs
> egg uninstall outdated       - uninstall all oudated eggs
> egg info pysqlite                    - show information about pysqlite
> egg info pysqlite/2.0.0      - show information about version 2.0.0 of pysqlite
> egg sync local                       - rescan local packages and update cache db

Sorry, but I think you meant apt-get instead of egg. No, I didn't
search the archives. But making an apt-get repository (yum, emerge...)
can't be *that* hard; it also can't be an uncommon idea. Someone must
have suggested it before.

On second thought, if I recall correctly Debian-style repositories
have to update a master Packages catalog for *each* and *every*
*single*  upload. That's a -1. I think you've asked for a "sync local"
master and I snipped it. Any other -1?

We'll, getting the repositores updated for each single upload becomes
O(N), but it's a small N anyway. One per supported repository format.


> Optional: These days XMLRPC (and the WS-Deathstar) seems to be losing
> steam to REST, so I think we'd gain a lot of "hackability" by
> enabling a REST interface for accessing packages.

Yep. Me likes dispatching on Accept: to get different responses. I
think Apache can do it with a type-map. Gotta read up on the
performance of it. That was an idea I stumbled upon during the recent
PyPI discussions.

Well, me likes flat files.

> Eventually we probably need to enforce package signing.

Heh, like the .deb and .rpm signatures? As I've said previously, I'd
like to have a standard-type-repository for PyPI. If we're
distributing binaries (has Phillip Eby said, sdist works *fine* for
source tarballs ) there are already people working on that subject.
Package signing's one of the for-free wheels we don't have to invent.
Squared wheels and all that.

So digital signatures' a +1.


> EGG IDEAS
>
> [snip]
> Perhaps "egg" should provide a simple web server to allow browsing
> (and perhaps installation from) local packages.

D*mn. Right now you just serve your .../site-packages and you can
easy_install from it (I think Phillip Eby said as much recently).

This standard-type-repository idea makes that a tad more difficult.

> If this web server should be discoverable via
> Bonjour/Zeroconf, then all that's needed to set up a cache of PyPI is
> to run an egg server (that people on the net auto-discovers) and
> regularly download all packages.

Maybe regenerating a bunch of static files isn't that difficult
anyway; do it before serving content. Well, you're gonna run a local
PyPI copy; might as well run the PyPI code anyway.

And now the collective asks: who the fsck is this Luis Bruno idiot?
Just one more Python user with some free time on his hands.

Greetings,
-- 
Luis Bruno