Imagine you are working on a smallish Catalyst project with an DBIx::Class model. You have been a good citizen and adhered to the principal of separation of concerns. Now you would like to extract the schema to use it anywhere else (in my case a monitoring interface that is in place and allows simple plugins). Creating a whole distribution with the related infrastructure out of the schema classes is just to much work for this one-off task. Dist::Zilla to the rescue.
]]>Dist::Zilla can't handle multiple dists in one directory,
so you have to create an empty subdir in the project.
I'll go with contrib/schema for now.
Put the following
name = MyApp-Schema author = You <you@example.com> license = None copyright_holder = You copyright_year = 2011 version = 0.01 main_module = lib/MyApp/Schema.pm [Manifest] [MakeMaker] [TestRelease] [Prereqs] DBIx::Class = 0 DBD::SQLite = 0 Test::DBIx::Class = 0 [GatherDir] root = ../../lib/MyApp/Schema prefix = lib/MyApp/Schema ; this is a hack to additionally gather the schema class ; maybe there is a better way, but I was not able to ; find a plugin that can gather files and also support ; a GatherDir-like prefix option [GatherDir / Schema] root = ../../lib/MyApp/ prefix = lib/MyApp/ exclude_match = (?<!Schema.pm)$ [GatherDir / Tests] root = ../../t/schema prefix = t/schema
Now change to the directory and run
dzil build
and you should have a shiny MyApp-Schema-0.01.tar.gz at your (not really best practice) disposal.
My last posting seems to have whet the appetite of a few people, or at least interested one or two enough to follow this project on GitHub. Today I'd like to delve deeper into how you can use App::Mist to deploy or distribute an application.
]]>I will use App::Mist itself as example for this mini-tutorial on how to use it. App::Mist is self-hosting and has few dependencies on its own, but you have to make sure that Dist::Zilla and App::cpanminus are present on your build system, otherwise everything will fail miserably.
In an ideal world, every package you depend on lives on CPAN, correctly lists its dependencies and passes its many tests with flying colors. The real world definitively is no such place, especially when viewed from the trenches, but for this post and for the installation of App::Mist we can make this assumption. How to deal with the inevitable hiccups in the dependency chain will be a topic for another two (or ten) blog posts down the road.
The App::Mist repository itself contains a mist environment and is self-hosting.
The script to run mist as a mist package is included.
For the rest of this post it is assumed that this script is available as mist in your path (e.g.
~/bin/mist) and you have adjusted the CHECKOUT variable according to your local conditions.
First clone App::Mist, e.g. via
git clone git://github.com/willert/mist.git
You will notice the unusual entries mpan-dist and mpan-install.
The directory mpan-dist contains a stable copy of all distributions needed to run the application,
and the script mpan-install is a fat-packed script directly derived from your (or mine in this case) cpanm that can install those distributions without any external dependencies.
Go ahead,
try it:
cd mist
./mpan-install
Run that command as normal user, because App::Mist will refuse to run with root privileges to protect you from accidentally modifying your system-wide perl installation.
This will install all dependencies from mpan-dist into the local lib (named perl5 by default as that seems to be the emerging naming convention) for this project.
If you created a mist script as mentioned above,
your copy of App::Mist is now ready to run.
Hopefully at least,
this is still alpha quality software.
You can check if everything is configured correctly with running
mist
without any parameters and be wow'ed by my skills at writing useful help messages!
I promised that App::Mist is self hosting,
so now its time to show you how to use your freshly installed mist to create its own distribution package.
First of all,
delete mpan-dist and mpan-install,
they are not needed at run-time.
Leave perl5 untouched for now,
or your mist script won't run anymore because of missing libraries:
rm -Rf mpan-dist rm mpan-install
To recreate the distribution run the following commands:
mist init # scan dist.ini and pick up all deps from cpan.org mist index # reindex the local mpan directory mist compile # build the ./mpan-install script
If everything works as expected, you should have created your first full-fledged mist environment! And if you ignore my long-winded ramblings, it was surprisingly fast and straight-forward, wasn't it ;)
To verify the distribution you can now throw away your local lib and created it anew:
rm -Rf perl5 # 'mist' is unlikely to work between those two steps ./mpan-install
Good luck, and please submit a bug report in the github issue tracker if anything went amiss.
]]>If you are working like me (which is unlikely) distributing and deploying your Perl5 projects poses a significant challenge. Managing self-contained projects has become vastly easier since the advent of local::lib, Dist::Zilla and App::cpanminus but the ever changing (and sometimes incompatible) nature of CPAN has bitten me more than once in my life as a coder. Here is how I try to solve this, judge for yourself if this approach has any merit and encourage me to go further down this path if you think it does.
]]>App::cpanminus included the --save-dists option for the first time in version 1.4 that was released this month.
It might not seem like a big deal at first,
but it got me thinking.
I was always looking for a nice and hassle-free way to manage a mini-cpan that is localized to a project and could easily be managed by source control.
Using a full mini-cpan for this simply couldn't be done due to size constraints.
A gig here and a gig there amounts to real space requirements when needed in dozens of projects.
Not to mention the pain of uploading and syncing this stuff.
Why would I want to do this?
Its simple: most of my work is done for a smallish web-shop with a grown infrastructure and tons of freelancers.
Every Ubuntu version from 8.04 to 11.04 beta can be found on our development machines and servers,
you can never be sure which packages are installed (especially on the dev machines) and if you are working with a 32-bit or a 64-bit variant of the OS,
nor which perl version is installed (although I would kick any of our freelancers that couldn't manage to get hold of at least 5.10.1).
Dist::Zilla and local::lib brought some improvements to this non-existing process,
but you are still at the whims of CPAN when installing from scratch.
Not to mention that local libs are not portable between different versions of perl and different host environments.
Don't get me wrong, I don't want to lay any blame here. In fact In am more than impressed how stable and glitch-free the installation of modules like Catalyst and DBIx::Class is, given that they have zillions of dependencies they don't control. But being on the road, having only your netbook available and getting a call to urgently fix something in a project you haven't touched for months (and thus no dev environment ready to dive into) sucks. The last thing you need right then is the fun of working around a temporarily broken toolchain or framework of choice that makes installing from CPAN a nightmare.
Even more fun, if the bug you are hunting is caused by a bug in a dependency that has since be fixed and the version of this library you are using in production has vanished from CPAN (you know, some people clean up their authors directory) ...
Maybe I am trying to solve problems no one but me has. Or there is any solution to this that I have missed that is not as complicated as Shipwright seems to be. The usual recommendations (fixed dev environment with company wide mini-cpan, custom apt-repositories, you name it) just don't cut it for me.
...
I've exhausted my blogging tuits (and probably your patience) for today,
but the good news is that I've managed to weave local::lib,
Dist::Zilla,
App::cpanminus and some fragments of mini-cpan style repository management into a nice small package that allows for easy tarball or VCS distribution of projects with no more requirements than a working perl and the theoretical ability to install from CPAN (cpanm is fat-packed into the deployment script) on the target machine.
Without further ado,
if you are interested in a distribution management package that can do this for you,
without requiring more than writing the usual dist.ini for Dist::Zilla,
check out the github repository for App::Mist and especially the workflow document and tell me what you think.
Cheers & have fun,
Sebastian
P.S. Prepending distributions needed by others that fail to list those dependencies (I'm looking at you, DBD::mysql) or simply fail some unimportant tests (Test::WWW::Mechanize, anyone?) is fully supported. Writing some checks to ensure the environment confirms to your expectations (pkg-config, C compiler, whatever ..) also is.
]]>(defun sbw/prereqs-to-dist-zilla () (interactive) (save-excursion (while (re-search-forward (concat "^\\(build_\\)?requires *['\"]\\([^'\"]*\\)['\"]" " *\\(=>\\|,\\)? *['\"]?\\([0-9_.]*\\)?['\"]? *[;,]") nil t) (replace-match (let ((module (match-substitute-replacement "\\2")) (version (match-substitute-replacement "\\4"))) (concat module " = " (if (string= version "") "0" version))) t nil) )) )Hope someone finds this useful... oh, and, yeah: first post!