Dist::Zilla::App::Command::bakeini - bake dist.ini to not need the bundles.
version 0.002007
cp dist.ini dist.ini.meta
dzil bakeini
less dist.ini # no more bundles :D
bakeini
is an App::Command
module for Dist::Zilla
that enables one to have two versions
of their dist.ini
, one which contains their bundle, and the other which is generated from the
first in a static and portable way, without requiring the bundle to be present.
This allows contributors and test targets to have a mostly "static" configuration that is less prone to randomly breaking your distributions every time you change something significant in your bundle.
It also allows contributors to only need the dependencies they really need, not the super-set of dependencies your bundle probably implies.
And at the same time, you still have the flexibility and power you normally have with a centralized configuration stored in a bundle, which you can roll out on demand, instead of having the roll out automatically propagate every time the bundle gets updated.
There's several long standing point of contention surrounding the use of bundles.
A few poignant ones that bother me are:
-
Bundles change over time and configuration parameters can change in validity
For example, I might add a requirement in a later incarnation of a bundle that a given parameter be specified. But that creates a confusing backwards compatibility problem for people who merely want to check out and build the code.
-
Some contributors tend not to like dealing with bundles due to bundle complexity
Bundles often declare far more dependencies than contributors need to build one specific distribution, and the bundle obscures the visibility of what plugins are being used.
This also manifests as a difficulty to work around problems produced by bundles such as bundles
use
-ing broken modules, which is not straight forward to iron out with the@Filter
bundle.@Filter
is also complicated for end users who are not familiar withdzil
to use, and@Filter
also lacks abilities to re-order plugins if that is necessary to avoid a bug.Additionally, routing configuration to a single plugin within a bundle can be confusing with messy syntax, especially if the bundle doesn't
do
ConfigSlicer
or something like that.And the effort of learning and using those tools is high if all you want to do is temporarily change a build setting for the point of local use or local testing.
So this command attempts to avoid these problems by separating the bundle from its configuration until configuration is wanted updated.
This means Dist::Zilla
based distributions DON'T have their build configuration radically changed simply because somebody
upgraded a bundle, and the configuration is MORE local to the distribution instead of being more global.
This means bundle specific configuration demands ONLY need to be satisfied during the baking process, but NOT every
subsequent build, and are thus NOT prone to causing a sea of unusable dist.ini
s if a bundle gets changed.
The biggest known downside of this approach at present is with much more advanced bundle usage.
Because the bundle itself is being taken out of the loop, that means dist.ini
will NOT be able to automatically have new
plugins added to it in response to changes in the tree. dzil bakeini
will have to be run subsequently to take tree changes
into consideration and emit updated configuration.
And because the bundle itself is being taken out of the loop, that means ENV
based controls in bundles will be bound at the
time of calling dzil bakeini
, which means if you're like @ETHER
and have an "Airplane mode", then:
AIRPLANE=1 dzil build
Won't work on a baked dist.ini
, and you will instead need:
AIRPLANE=1 dzil bakeini && dzil build
Though, that could be beneficial too depending on how you use it.
# Get on the plane
AIRPLANE=1 dzil bakeini
# dzil runs everything in airplane mode now
dzil build
# Get off the plane
dzil bakeini
# dzil runs normally
dzil build
If you want to codify some unique behavior to how your bundle performs under dzil bakeini
, ( for instance, to change the prereqs
advertised as being develop.requires
)
Here, ::Util::CurrentCmd
comes in handy:
use Dist::Zilla::Util::CurrentCmd qw(current_cmd);
my @config;
...
if ( 'bakeini' eq ( current_cmd() || '' ) ) {
push @config, [ 'baked dist prereqs', 'Dist::Zilla::Plugin::Prereqs', { 'Foo::Bar' => 2 }];
} else {
...
}
--comments
allows to control which comments are copied into the target dist.ini
DEFAULT Inject all comments regardless
Inject all comments that are Dist::Zilla
AuthorDeps
Inject no comments.
Kent Fredric kentnl@cpan.org
This software is copyright (c) 2017 by Kent Fredric kentfredric@gmail.com.
This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.