#--------------------------
Need to add the 'documentation' key to all my attributes. Also, need to figure out how to get Pod::Weaver to consolidate
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.
Actually, I think it is good enough for now
Not yet -- no clear use case.
In no particular order...
Like to notify people when the repository contents have changed. Or to kick off a build when the repository changes.
To excplicitly declare what packages the archive provides, in cases where the META is whack or the packages can't be discovered.
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.
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.
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.
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.
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.
Only the command-line interface has any real documentation. The internal API has started to become stable and needs to get some documentation love.
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.
To install Pinto, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Pinto
CPAN shell
perl -MCPAN -e shell install Pinto
For more information on module installation, please visit the detailed CPAN module installation guide.