Let's sketch out what the internal architecture of the tool might look like, at a high level.
Here's a few of the objects/classes we might want to create and use.
The logic for the command-line interface, including option parsing because most of the current python option parsers suck. We'll probably need to write our own... maybe we could even make it generic enough to break out into a project of its own that other people could use.
I want to take a hint from Mercurial here and use a "ui" object for input/output instead of straight print statements.
This makes it really easy to change formatting and add color down the road. It also allows you to redirect output for unit tests without monkeypatching sys.stdout.
The repository-handling logic should be abstracted away so that the rest of the tool doesn't have to care what kind of repo a particular library has been checked out with. The rest of the program should be able to write
repo.tags and get the correct result no matter what kind of repo is powering it.
A Mercurial repo. It'll have to process the command-line interface to avoid licensing issues, but that's not too bad. Mercurial has a great, flexible CLI so we should be okay.
We'll probably want to parse git's CLI too to avoid licensing issues. I'm not sure how well this will work because I haven't had quite as much experience with it.
This won't really be a repository, it will be the fallback if the project is using tarballs instead of repos. It should mimic a repo though, so you can do
repo.tags and it will give back a list of "tags" (which it could actually pull from the card file).
A Card object should be a wrapper around individual modules in the catalog (see CardCatalog). For example, if there's a 'hyde.py' file in the catalog/ directory, you should be able to use
c = Card('hyde', create=False) to get the wrapper object.
I don't know if we really need this. I was thinking it could be an easier way to manage Cards, but it's probably overkill.
A "Shelf" is the concept of a checked-out (or downloaded) project. It may or may not be installed (i.e. symlinked into lib & bin). This is what would use the *Repo objects, and this is what the CLI would talk to if it wanted to know, say, what version of "mercurial" is installed right now.