PRIORITIES

Rethink the API for getting/opening/committing stacks

Extract versioning stuff to a separate dist.

Command to unregister a pkg/dist

Command to examine the delta between two stacks or revisions

Add versioning to the stack props

Add stack props and repos props to the dump META

Create command to load repository from a dump

Try to ensure integrity of commits

Refactor the Initializer class

#--------------------------

Attribute to indicate of package was explicitly requested for stack

Improve locking mechanism (one lock per stack, maybe in db).

Consider using natural keys for package/dists.

Consider pinning at dist level, not pkg

Command to list dependors and dependants

Command to verify prereqs on a stack

Write test cases for Stack operations

Command to list outdated packages

Command options to specify provided/required packages (maybe not)

Stack property: strict (no overlapping dists) ??

Stack property: target perl

Stack property: source repositories

Stack property: allow devel releases

Repo property: log level

Repo property: default sources

Repo property: default target perl

Repo property: defautl devel option

Prettier stack listing and stack prop listing

Re-examine log levels for messages

Should we have an heirarchy of exception classes

Verify archive checksums during 'verify'

Add hooks before/after adding and pulling

Give revisions properties ??

Allow revisions to be tagged

Mark stacks as merged after merge

Mark stacks as deleted after delete

Warn if an unmerged stack is being deleted

Way to pin/unpin all packages in a stack

Make the Store transactional

Rewrite tests with Test::Class

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

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.

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.