'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 _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
