Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/kentnl/dist-zilla-app-command-bakeini

bake dist.ini to not need the bundles
https://github.com/kentnl/dist-zilla-app-command-bakeini

dist-zilla perl

Last synced: about 1 month ago
JSON representation

bake dist.ini to not need the bundles

Awesome Lists containing this project

README 

        
# NAME



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



# VERSION



version 0.002007



# 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.ini`s 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`](https://metacpan.org/pod/Dist::Zilla::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 



# COPYRIGHT AND LICENSE



This software is copyright (c) 2017 by Kent Fredric .



This is free software; you can redistribute it and/or modify it under

the same terms as the Perl 5 programming language system itself.