NAME

Dist::Zilla::App::Command::bakeini - bake dist.ini to not need the bundles.

VERSION

version 0.002006

SYNOPSIS

cp dist.ini dist.ini.meta
dzil bakeini

less dist.ini # no more bundles :D

DESCRIPTION

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.

DISCUSSION

The Quibbles

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 with dzil 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.

The Benefits and Method

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.inis if a bundle gets changed.

The Downsides

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

TIPS AND TRICKS

bakeini dependent behavior in a bundle

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 {
  ...
}

PARAMETERS

--comments

--comments allows to control which comments are copied into the target dist.ini

all

DEFAULT Inject all comments regardless

authordeps

Inject all comments that are Dist::Zilla AuthorDeps

none

Inject no comments.

AUTHOR

Kent Fredric <kentnl@cpan.org>

COPYRIGHT AND LICENSE

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.