--fake and --pure

[Leont]

Module::Build currently has two extra install actions: fake_install and pure_install.

The former is of somewhat limited use IMO unless you're writing a build system, but ExtUtils::Install has explicit support for it in the form of the dry_run argument.

The latter is more useful, as it guarantees that no perllocal is written. Currently in M::B, it's synonymous to install, though I'd like to change that in the future.

That said, this system is not scalable. Obviously, you can't combine fake and pure this way, and if we implement the install database we discussed in Lancaster this problem will only become worse.

Therefor, I propose we'll use flag arguments instead. e.g. ./Build install --fake --pure. That way we'll have plenty of space to grow in the future.

[karenetheridge]

On Sun, Oct 27, 2013 at 05:18:03AM -0700, Leon Timmermans wrote:

Therefor, I propose we'll use flag arguments instead. e.g. ./Build install --fake --pure. That way we'll have plenty of space to grow in the future.

Agreed - 'install' is the action; 'fake' and 'pure' are only modifiers to
that, and shouldn't be separate actions.

Here's my concern -- do we want to encourage per-action modifiers?

Or do we want to push towards a model where everything gets set just in configuration and then actions are just actions?

For CPAN clients, I see no practical point of fake install, so I don't know that we need that defined in the spec, though I think it's a useful thing.

I find the term "pure" to be vague. And what if there are competing standards for post-installation information recording? Do we have to proliferate options to turn them on and off?

David

[Leont]

Here's my concern -- do we want to encourage per-action modifiers?

Or do we want to push towards a model where everything gets set just in configuration and then actions are just actions?

I'm not sure I understand what else you're proposing.

I find the term "pure" to be vague.

It is, but AFAIK in this context it means "Never modify/append files, only create/overwrite them". This is important in many packaging systems. This is functionality that is already used/needed today.

And what if there are competing standards for post-installation information recording? Do we have to proliferate options to turn them on and off?

Hopefully not.

I'm not sure I understand what else you're proposing.

Just playing around:

perl Build.PL --no-perllocal
./Build install

Instead of

./Build install --no-perllocal

I was thinking about the original mess of .modulebuildrc and "*". Do we want a system with lots of options and toggles? Particularly ones that are action-specific? Where clients have to be specific about which options get used when. For example, CPAN.pm has action-specific configuration options for M::B and EU:MM.

Do we want more of that sort of thing, or more of a "configure-once" model, where all options are given to Build.PL and then actions do one and one only thing given those options.

That would avoid potential conflicts between options given during configuration and options given later. Or conflicts between PERL_MB_OPTS and things set by cpan clients. The more places options can be set, the more potential there is for complexity, confusion or error.

I'm not sure if it's really a big problem (we already have some of it). I'm not sure which model I prefer, really. But I want to get the question on the table for consideration.

[Leont]

Do we want more of that sort of thing, or more of a "configure-once" model, where all options are given to Build.PL and then actions do one and one only thing given those options.

The current model supports both, and I see no need to change that (I suspect that boat has already sailed), but I do think it is a good idea to promote the former over the latter.

[karenetheridge]

I was thinking about the original mess of .modulebuildrc and "*". Do we want a system with lots of options and toggles? Particularly ones that are action-specific? Where clients have to be specific about which options get used when. For example, CPAN.pm has action-specific configuration options for M::B and EU:MM.

Do we want more of that sort of thing, or more of a "configure-once" model, where all options are given to Build.PL and then actions do one and one only thing given those options.

It is probably reasonable (and not too messy) to store all the Build.PL
arguments as variables in the generated Build file. However the idea of a
.modulebuildrc that stores settings across multiple dists is something we
should move far, far away from. Settings are dist-specific, not
user-specific, so there should only be very very few options that can be
set by the user that take effect across all dists (I'm thinking of settings
like PERL_MB_USE_DEFAULT as one of the few exceptions).

That would avoid potential conflicts between options given during configuration and options given later. Or conflicts between PERL_MB_OPTS and things set by cpan clients. The more places options can be set, the more potential there is for complexity, confusion or error.

+1

there should only be very very few options that can be set by the user that take effect across all dists (I'm thinking of settings like PERL_MB_USE_DEFAULT as one of the few exceptions).

Interesting to think about. The current .modulebuildrc and PERL_MB_OPT approach is that those just set command line options and any valid command line option is acceptable there.

Thinking about "--pure" (or some better name) -- that is really a user-specific option that should apply to any install. It's not a separate "action" (because you can't force your CPAN client to run "./Build pureinstall" instead of "./Build install".

[Leont]

Settings are dist-specific, not user-specific, so there should only be very very few options that can be set by the user that take effect across all dists.

Build settings are dist-specific, install settings are user-specific.

[kenahoo]

On Tue, Oct 29, 2013 at 5:37 AM, Leon Timmermans
notifications@github.comwrote:

Do we want more of that sort of thing, or more of a "configure-once"
model, where all options are given to Build.PL and then actions do one and
one only thing given those options.

The current model supports both, and I see no need to change that (and
even if we wanted that, I suspect that boat has already sailed), but I do
think it is a good idea to promote the former over the latter.

I don't support that trend. It's very useful when installing things
interactively to change options on a per-command-invocation basis.

-Ken