Support for pulling prerequisites described in a cpanfile.

[hartzell]

Hi Jeff,

Here's a first cut at support for reading prerequisites from a cpanfile.

I ended up slipping it into the Pull action, it seemed to be minimally disruptive and I couldn't bring myself to cut-and-paste the rest of the Pull stuff.

Added a test to make sure that handling no targets and no cpanfile does the right thing and added a bunch of tests for various cpanfile monkeyshines. I'm not entirely sure that I'm using the test stuff to its fullest potential.

Comments, please.

[thaljef]

I see: cpanfile.snapshot is the new name for carton.lock.

[hartzell]

ps. There's an obvious fancier step of adding command line switches to explicitly specify phase/type. Not sure if it's worth it, whether it's better to specify e.g. "test and everything below" or name each individually, etc... Wait for a use case....

[thaljef]

This looks great. Try it for a while and then we can think about merging it.

Lately, I've been looking into extending Pinto to support Ruby and/or Python. So I might prefer to put this in a separate command, since it is very Perl-specific. But we'll cross that bridge when we get to it.

[thaljef]

Some thoughts...

If we add --cpanfile to the pull command, the next logical step is to add it to the install command. Therefore, I would want to create a role (maybe Pinto::Role::CpanfileReader) that does the work of turning a cpanfile into a list of targets.

Supporting --cpanfile with remote repositories is a bit tricky because the client will have to read the file locally, translate them into targets, and then send the request to the servers. I guess it could also just send the cpanfile itself to the server, but that doesn't seem right to me.

Either way, the solution is to create a custom Pinto::Remote::Action subclass that does the necessary client-side stuff. Pinto::Remote::Action::Add and Pinto::Remote::Action::Install are examples of this. All other commands just use the Pinto::Remote::Action base class which simply packs the arguments into some JSON and POSTs it to the server.

I see that you also had to tweak some stuff up in App::Pinto::Command. That is probably unavoidable, but I want to look at that carefully. It might also make sense to make the argument for --cpanfile optional, and default it to just ./cpanfile since I think that is the customary filename.

Down the road, it will probably make sense to have options that affect what Pinto does with respect to prereqs for different phases (e.g. configure|build|test|runtime|develop) which would also impact how the cpanfile is used. But I haven't figured out what that should look like.