PRIORITIES

Exception hierarchy/handling

Current regime is too complicated. Maybe just croak on any error, rather than trying to continue with the rest of the batch.

LESS IMPORTANT

Documentation review

Need to add the 'documentation' key to all my attributes. Also, need to figure out how to get Pod::Weaver to consolidate

API documentation

Support target_perl option

So you can specify which perl to compute dependencies with. Because the perl you want to deploy with may not be the one that you use to run Pinto.

More robust list action

Actually, I think it is good enough for now

Query language?

Not yet -- no clear use case.

IDEAS FOR COOL NEW ACTIONS

look: Unpack archive in temp dir and launch shell there

ack: Do an ack command across all distributions

news: list recent additions. maybe something from Changes file

assign: change ownership of a distribution

OTHER STUFF TODO

In no particular order...

Create a hook mechanism to do stuff before or after an Action

Like to notify people when the repository contents have changed. Or to kick off a build when the repository changes.

Enable plugins for visiting and filtering. See CPAN::Mini and CPAN::Mini::Visit.

Standardize API, using named parameters except where it makes sense not to.

Write a tutorial to explain different ways for using Pinto in the development/deployment cycle. ++

Generate a RECENT file. This could just contain the files added in the last action (if any).

Improve Perl::Critic compliance.

Document, document, document.

Tests, tests, tests.

Look for better ways to use Moose roles.

Look into using Path::Class::SVN or Alien::SVN instead of using my home-grown interface to Subversion.

Profile and look for performance optimizations.

Add --package option to the Add action

To excplicitly declare what packages the archive provides, in cases where the META is whack or the packages can't be discovered.

STUFF DISCUSSED WITH RJBS

Features inspired by XPAN

Implement a "dry-run" feature.

Whenever Pinto fetches a .tar.gz, it first puts in a temporary directory (I think). After the packages and prereqs have been extracted, only then does it actually place it in the repository. So if --dryrun is enabled, don't put it in the repository. Also, if --dryrun is enabled, roll back the database transaction. There might be multiple layers of transactions going on, so we'll have to roll back at the right level. Finally, each Action must return 0 if --dryrun is enabled, to indicate that the repository state has not changed and does not need to be committed to VCS.

Warn when an imported/added package conflicts with a pinned package.

Each time a package is added, Pinto looks at all the other packages with the same name and sorts them according to version number, whether it is pinned, and whether it is "local" or "foreign". From that, it determines what the "latest" version is and marks that to be included in the index. So that would probably be the time to warn if an incoming prereq is blocked by an older pinned package.

Other housekeeping chores that need to be done...

Optimize generation of CHECKSUMS files.

At the moment, I'm using Adreas' module, which generates a CHECKSUMS file by recomputing md5s for everything in the directory. I think this is because PAUSE is paranoid about keeping accurate CHECKSUMS. But this makes importing/adding/mirroring slow if the author's directory already contains a lot of dists. Better to just compute the md5 for the new dist and append it to the ones that are already in the CHECKSUMS file.

Come up with a strategy for schema migration.

I'm using SQLite and DBIx::Class. Every time the database schema changes, I break compatibility with all the existing repos (if there are any). So I need some way for Pinto to upgrade its own schema. I know there are frameworks for doing this but I just haven't learned them. Or maybe just use something like KiokuDB.

Document the architecture.

Pinto has a pretty well-defined architecture -- there are distinct layers and separations of concern. It may not be the *right* architecture, but it is definitely there. I need to capture it on paper so I (and others) can reason about it.

Document the API.

Only the command-line interface has any real documentation. The internal API has started to become stable and needs to get some documentation love.

Grand wishes...

Make Pinto extensible in the way that Dist::Zilla is.

For example, I can imagine roles like BeforeAddition/AfterAddition and BeforeRemoval/AfterRemoval that provide hooks where plugins can make stuff happen when a dist is added or removed from the repository. Stuff like publish the POD to a website, or tweet a notification, or fire off a build, or run a local metacpan. But that all may be premature.