Saved By Pinto
That title may remind you of a certain song by The Fixx.
Last week a new version of CPAN::Meta was shipped to CPAN. Unfortunately, it caused a test to fail in Module::Build. In turn, that set off a whole chain of downstream failures in hundreds of distributions that depend on Module::Build.
So if you were building up a complete application stack last week (like on Stackato or Heroku) and you were pulling the latest dependencies from CPAN, you were hosed. This sort of thing happens all the time, and when it bites you, it will be at the worst possible time.
Pinto also uses Module::Build. But those who were building it with the installer at http://getpinto.stratopan.com were completely insulated from the failure. This is because the installer pulls dependencies from a private repository. Unlike the public CPAN, that repository is stable and only changes when I decide to upgrade or add a dependency.
Fortunately, the problem with CPAN::Meta was short-lived. Dave Golden had released a fixed version only 23 hours later. But I think this perfectly demonstrates why you should lock down your dependencies with a tool like Carton or Pinto.
Hacker, speaker, author, dad.
I've often heard Schwern say that he's one of the few people that can ruin CPAN for anybody if he messes up ExtUtils::Makemaker or Test::More. Sometimes he says it as a concession to fragility, but sometimes it sounds vaguely threatening. :)
I should also note that people can solve this without something like Pinto by having an upgrade strategy that isn't "try it in production and see what breaks". Pinto, DPAN, Carton, and so on are there when you deploy to a test environment and find that it breaks because someone broke the public CPAN. These systems can break in the same way, but they let you rollback those changes, where the real time module index doesn't.
I haven't looked closely at Carton, but I have a rough idea how Pinto works, and I know how DPAN works. I'm low tech. I drop a bunch of tarballs into a directory and create a CPAN out of it. Pinto has features on top of that basic idea so you can manage which tarballs you choose. I'm still playing with it though, but my interest has mostly been in the "ground truth" of the metadata.
Brian:
the basic idea of carton is just simple as exactly you said - you have a mapping of modules to distfiles (AUTHOR/Dist-Name-ver.tar.gz) you verified that works with your app. and carton lets you manage that list, and commit that to your git.
And then use that as a source of CPAN to install on the deployment environment. Basically the same thing with "having a bunch of tarballs and create CPAN out of it".
But it's done in a more app/VCS friendlier way, as well as you have a DSL (cpanfile) to manage pin-pointing to a specific version (e.g. requires 'Module', '== 1.0') without manually fiddling with tarballs yourself.
That's basically it.
I'm trying to set up a deployment system with Carton and Pinto. One thing I'm concerned about is that it seems that Pinto wants to only have one version of each module in each "stack", whereas Carton records every version of every module, and is, of course, project-specific. So, what happens if one project updates a module in Pinto? Won't that cause projects whose cpanfile.snapshot point to an earlier version to break?
How do people deal with this? Do they "pin" each and every version that appears in a cpanfile.snapshot anywhere? Do you have one "stack" per project?
If there's a mailing list better suited to this question, could you let me know?
Thanks!