add --no-exec option. it skips exec after installation

[sett4]

Hi Nathan,

This changes adds --no-exec option.

conscript executes launchconfig after install. ( https://github.com/n8han/conscript/blob/master/src/main/scala/apply.scala#L35 )
installing xsbt, conscript launches screpl. screpl waits user inputs.

This changes allows to skip exec after installation.
I don't know this changes right fix or not...

Thanks,
Setsu

[eed3si9n]

I wonder if our decision to execute script with --version was not careful enough.
I had users complain about scalaxb erroring out on install (unknown option --version), so I had to actually add --version option.

Not sure if this is ok, but maybe we could define our own entries in launchconfig for this, so the end user doesn't have to know to call cs with --not-exec or whatever.

[n8han]

I wonder if our decision to execute script with --version was not careful enough.

There was a good reason to run the script immediately, I just forget what it was. Was it just that we think an installer should finish downloading something before it claims success? There's also the potential that if you say something is installed, somebody might believe you and plan on using the command later when they don't have internet connectivity.

Not sure if this is ok, but maybe we could define our own entries in launchconfig for this

I'm not sure what you mean there.

I do wish the sbt-launcher itself had some built in dry-run functionality, that simply fetched dependencies without calling the target app. I guess one way to solve this, properly, would be to send a pull-request for that feature to Mark.

Alternatively, we could provide some better rigging for conscript apps that handles --version for them. If all apps handled the parameter, as we originally imagined they would, it would work well. But then, we are talking about sbt, and I don't really expect sbt to use any conscript rigging.

[eed3si9n]

Not sure if this is ok, but maybe we could define our own entries in launchconfig for this

I'm not sure what you mean there.

So launchconfig is basically an ini file that's used by sbt-launcher, but I was thinking we could add a new section that describes the behavior of conscript like the following:

[conscript]
  dry-run-param: --version
  dry-run: false

This way each app authors can provide their own dry-run parameter without telling the end user to install their app with some custom command line option.

[n8han]

As I see it, the problem is that app authors do not expect to have to do anything in particular for conscript (and we don't tell them otherwise). I don't think they want to be able to specify another kind of dry-run parameter; they just don't want to have to deal with it at all. It's probably a bit easier for them to say "dry-run: false" in the launch config than it is for them to implement a dry run, but we decided previously that that produces a poor user experience.

It's worth mentioning that the conscript launchconfig creator and the app author are not necessarily the same person. Maybe the app author doesn't have time to implement any kind of dry-run parameter, but the person writing the launch config is more motivated. It's also easier to update the launch config than it is to release an app update.

Is there something we can pass to screpl to cause it to bail out?

[n8han]

One more quick comment, maybe we should assume --version is not supported by the app and encourage people to 1) implement it and 2) flag it as implemented. This would restore good behavior for screpl, etc, and provide a path for people to make their own install experience better.

[eed3si9n]

we should assume --version is not supported by the app

You mean like catch the error and not print the error message out to the end user, but print some friendlier message? That could be a nice sweet spot of usability.

[eed3si9n]

No, but for Setsu's case, the program doesn't return until the user inputs..

[n8han]

Right. I meant, don't call exec at all unless there is configuration to say that the app supports the parameter.

That is, I'm considering reversing my position. It's pretty confusing. :)

[eed3si9n]

Ok. Let's open a case for that and close this pull request.

[n8han]

Sounds good.