[Catalog-sig] [Distutils] Simpler Python package management: the "egg" command
eu at lbruno.org
Thu Aug 16 19:12:12 CEST 2007
> * 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
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
> 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.
More information about the Catalog-SIG