Carmel
view release on metacpan or search on metacpan
# Roll out the currently selected modules into ./local
carmel rollout
# package modules tarballs and index into ./vendor/cache
carmel package
# use Carmel packages inside a script (without carmel exec)
perl -e 'use Carmel::Setup; ...'
# prints export PATH=... etc for shell scripting
carmel export
# find a module in a repository
carmel find DBI
# find a module matching the version query
carmel find Plack ">= 1.0000, < 1.1000"
DESCRIPTION
Carmel is yet another CPAN module manager.
Unlike traditional CPAN module installer, Carmel keeps the build of
your dependencies in a central repository, then select the library
paths to include upon runtime in development.
Carmel also allows you to rollout all the files in a traditional perl
INC directory structure, which is useful to use in a production
environment, such as containers.
WORKFLOW
Development
During the development, run carmel install when you setup a new
environment, and any time you make changes to cpanfile. This will
update your build artifacts, and saves the changes to
cpanfile.snapshot. Commit the snapshot file in version control system
so that you can reproduce the exact same versions across machines.
carmel exec makes it easy to run your application using the versions in
cpanfile and cpanfile.snapshot dynamically.
# On your development environment
> cat cpanfile
requires 'Plack', '0.9980';
requires 'Starman', '0.2000';
> carmel install
> echo /.carmel >> .gitignore
> git add cpanfile cpanfile.snapshot .gitignore
> git commit -m "add Plack and Starman"
# On a new setup, or another developer's machine
> git pull
> carmel install
> carmel exec starman -p 8080 myapp.psgi
# Add a new dependency
> echo "requires 'Try::Tiny';" >> cpanfile
> carmel install
> git commit -am 'Add Try::Tiny'
# Update Plack to the latest
> carmel update Plack
Production Deployments
Carmel allows you to manage all the dependencies the same way across
development environments and production environments. However, there
might be cases where you want to avoid running your application with
carmel exec in production, to avoid the overhead with large number of
include paths, or to avoid installing Carmel in the production hosts.
Carmel provides two easy ways to avoid depending on Carmel on the
deploy target environments. First, carmel rollout rolls out the build
artifacts into a regular perl5 library path in local. Once the rollout
is complete, you can include the path just like a regular local::lib
directory.
# Production environment: Roll out to ./local
> carmel rollout
> perl -Ilocal/lib/perl5 local/bin/starman -p 8080 myapp.psgi
You can run carmel rollout> in a CI system to create the local
directory next to your application code for a linux package (e.g. deb
package), or Docker containers.
Second, carmel package (similar to carton bundle) creates a directory
with tarballs and CPAN-style package index files, which you can pass to
cpanm on a target machine. This way, you only need cpanm, which is
available as a self-contained single executable, to bootstrap the
installation on a host with a stock perl.
# Vendor all the packages to vendor/cache
> carmel package
> git add vendor/cache
> git commit -m 'Vendor all the tarballs'
# Remote environment (CI etc.)
> git clone https://.../myapp.git && cd myapp
> cpanm -L /path/to/lib --from $PWD/vendor/cache -nq --installdeps .
HOW IT WORKS
Carmel will keep the build directory (artifacts) after a cpanm
installation in a repository, which defaults to
$HOME/.carmel/{version}-{archname}/builds, and your directory structure
would look like:
$HOME/.carmel/5.20.1-darwin-2level/builds
Plack-1.0033/
blib/
arch/
lib/
URI-1.64/
blib/
arch/
lib/
URI-1.63/
blib/
arch/
( run in 1.391 second using v1.01-cache-2.11-cpan-5a3173703d6 )