need better support for plugins in ~/.dzil/config.ini

[karenetheridge]

Some plugins would be better situated in the user's local configuration (~/.dzil/config.ini) rather than in the distribution's dist.ini -- for example, [InstallRelease], which installs the dist tarball using a configurable command (different users might want to use a different command to install, or not install at all).

I discovered while writing Dist::Zilla::Plugin::Chrome::ExtraPrompt that loading plugins via config.ini did not work very well. Let's add better support! Or, figure out why this is a bad idea and find other ways to accomplish machine- and user-specific customizations.

[karenetheridge]

[Twitter] is another plugin that would go better as a user-specific plugin rather than dist-specific.

[dolmen]

In general, many AfterRelease may be user-specific. Those that aren't are those that are a mandatory step of the workflow, like [NextRelease].

[karenetheridge]

Agreed: [Git::Commit], [Git::Tag] and [Git::Push] should stay with the dist IMO, but others, such as [Run::After*] may be user-specific (e.g. my bundle updates a few local symlinks and .ackrc after every successful build, which might be annoying for others).

[karenetheridge]

Also [ArchiveRelease] and [Clean] are more user-specific than dist-specific.

[dolmen]

[ArchiveRelease] may not user-specific. Think about multiple users working on the project, and committing the archive in the repository is part of the release policy. You don't want one user to be allowed to make a release without archiving it.

[Clean] is 100% user-specific.

[karenetheridge]

ArchiveRelease] may not user-specific.

It may not be, but it's definitely machine-specific. There's no gain made from releasing a distribution on another machine, where the archive is not accessable to anyone else. (or worse, the archive directory doesn't exist there, so kaboom!)

[dolmen]

@karenetheridge I'm not sure you've seen I tweaked my comment probably while you were reading its first version.
The case of a distribution with multiple releasers with a shared directory must be considered.

[karenetheridge]

On Tue, Aug 05, 2014 at 04:28:57PM -0700, Olivier Mengué wrote:

@karenetheridge I'm not sure you've seen I tweaked my comment probably while you were reading its first version.
The case of a distribution with multiple releasers with a shared directory must be considered.

Okay yes, in that case you may want [ArchiveRelease] to be in the dist.ini,
if it's an essential part of the process.

In that case, where the release needs to occur from a specific machine
(where the archive directory lives), waiting to die until [ArchiveRelease]
runs is too late -- a user may have already released from the wrong
machine. There would have to be another check, at BeforeRelease time, that
the directory exists. A simple check with [Run::BeforeRelease] should be
sufficient for that.

(BUT all this is beside the point of the original issue topic. this
is what happens when two pedants talk to each other!!) :p

[rjbs]

My solution for most of these problems would be to have (for example) [Twitter] in the dist.ini, but look for a stash for its config, with a skip_if_unconfigured boolean option. If true, no config means no Tweet. Otherwise, it's fatal.

This doesn't address run-after-release. Do you have things you want to run after release, for example, when releasing dists that you don't "own"? Can you give me a more concrete example?

[karenetheridge]

The plugin I've had in use for years in ~/.dzil/config.ini is [Chrome::ExtraPrompt], but this is a bit of a special snowflake in another sense because it doesn't run at any specific build phase but rather modifies the Chrome object to extra stuff.

I could certainly see a specific author wanting to do at-release operations from their personal configs though, such as things provided by [Twitter], [ArchiveRelease] or [Run::AfterRelease]. Having a plugin look in a user's local configuration for addtional configs (and bailing if there are none) is certainly useful in some cases, but pretty much orthogonal to what I was going for here.

I was trying to figure out how difficult it would be for config.ini to also be able to add plugins to the $zilla->plugins list, and thereafter they would behave normally, as if they came from dist.ini. (They would have to be added in a defined order - probably adding them after the dist.ini list would be more useful than having them added first.) The problem is that config.ini plugins have their register_component sub called (via Config::MVP), but thereafter they are ignored -- they are not instantiated as objects and appended to the plugin list, etc. It's been a few years since I was in this area of code, but I can see in Chrome::ExtraPrompt's code that register_component is called with a $section object where there is no zilla attribute.