I shipped a few trial versions of Carmel to CPAN. Carmel is intended to be a successor of Carton, with a better internal structure and an interesting architecture change. As a starter, here’s how Carton works:
- use local::lib and cpanm’s -L option to install modules locally to ./local
- Scan meta/install.json file cpanm created under ./local and create a snapshot file
- for the next run, if there’s a snapshot, create 02packages file and prefer that but could cascade to CPAN mirror
carton exec is just -Ilocal/lib/perl5 This has been working fine, but with a few issues:
- for a new project or a new checkout, it is always a full install and could take a lot of time
- there’s no safe way to rollback a module. You just revert it in snapshot and hope it gets reverted correctly.
To guarantee a safe rollback you have to remove the ./local directory to start over, and that could be really slow. Carmel changes this by working like:
- still use cpanm -L option, but it installs to a cache target, and installed modules wouldn’t be used
- instead, copy the build artifact that has blib directory in it
- after install, scans the entire artifacts to find what matches your cpanfile requirements
- creates a snapshot like Carton (not implemented yet)
- carmel exec gathers the matching list of build directories and push them to @INC and let perl 5 load the right modules from right location. So, for an end user, it almost works like Carton — I even plan to reuse the .snapshot format so that upgrade is painless — but the internals are quite different. The nice benefit is that even for a new project for a checkout, as long as you have a satisfying version in the cache, the installation is within seconds, not a full install.
It’s still premature and not everything has been implemented, but Carmel is on github.
If this works out really well, there’s a chance that Carmel just becomes Carton 2.0, since having two tools that does the same thing could confuse developers. But given the drastic change in the internals and operational changes in deployment strategy, leaving them under two different names could be fine for me too.
Carmel doesn’t solve the wishlist for Carton a lot of you might have had: pinning to a git checkout, just yet — but that’d be a lot easier if we get this right!