Behaviour when working with packages and setting options.

[jfdm]

Currently when building packages from the command line, all options not included in the ipkg file are ignored. For example, given the command below:

$> idris --log 3 --build foobar.ipkg

The logging level is not set to 3. This default behaviour is counter intuitive in the cases that someone wishes to quickly add options when developing packages. For example: setting logging levels, setting verbosity output, setting warning flags et cetera.

I think the default behaviour should be that the options used when building a package should be the union of those specified in an ipkg file, and those specified on the command line. Furthermore, in the event that two options clash, I think that the options from the command line should have precedence.

This should be flagged as low hanging fruit/be a mini project.

[david-christiansen]

I am in agreement that this makes sense, but perhaps the semantics at this time should just be concatenation of arguments? Otherwise, the overriding behavior might be somewhat difficult to precisely specify, given the current underspecified nature of the semantics of combining arguments. For example, -p should clearly not invalidate the -p options in the .ipkg, but others should.

[edwinb]

I wonder if this should only apply to certain arguments (--log is a good example) and any invalid ones should report an error rather than being combined.

On 31 Jul 2014, at 09:05, David Christiansen notifications@github.com wrote:

I am in agreement that this makes sense, but perhaps the semantics at this time should just be concatenation of arguments? Otherwise, the overriding behavior might be somewhat difficult to precisely specify, given the current underspecified nature of the semantics of combining arguments. For example, -p should clearly not invalidate the -p options in the .ipkg, but others should.

—
Reply to this email directly or view it on GitHub.

[jfdm]

Yes and yes. When implementing this feature the behaviour behind the union of option sets should be decided upon first. When presented with two like options the behaviour should be either to:

1. concatenate to the already given set of options.
2. override the set option with the given option
3. warn over setting the option.

As to how this behaviour should be assigned to each flag is left for the implemented.

[jfdm]

Going through some old issues and noticed that Issue #499 might actually be a symptom of this.