Bootstrapper magic mode & run

[vbfox]

Bootstraper Magic mode (And also --run but that's boring)

It add 2 features to the bootstraper:

• --run when passed all arguments after it are ignored and when paket.exe is downloaded it's started with the remaining arguments
• Magic mode similar to some unix binaries that change behavior when renamed, the bootstraper when renamed to paket.exe behave just like it !
  • Download the real file to the temp directory and assume --run
  • Except if --run is really passed, pass all it's arguments to paket.exe as-is
  • Keep using the same file without checking for updates for 12 hours (Assume --max-file-age=720)

The end result is that the bootstraper paket.exe can be placed at the root of a repository avoiding the need of shell scripts, cmd scripts or even a .paket folder.

The "first time user" experience is also much better : place paket.exe in solution root then paket init. You can commit it, it's small and keep itself up-to-date.

PS: The bootstraper gain 4KB moving from 39KB to 43KB

[vbfox]

Still WIP as the console ends up slightly corrupted on MacOSX, don't know if it's fixable.

[vbfox]

I think this PR is ready for being tested/checked @forki . It should be labeled as "alpha" or something like that until it's tested on more platforms / by more people.

I had some problems on mono/unix but I think they are now solved with the latest commit working without problems on the systems I have access to. If anyone is interested in the murky little details UnixMonoConsoleRunner.cs contains a bunch of comments.

Tested on:

• Windows 10
• Bash on Ubuntu On Windows
• MacOSX sierra

[baronfel]

Oh nice, lemme give this a spin on my own and windows boxen

[baronfel]

With the PR should we also update the paket.targets to use the new paket.exe convention? The paket.targets that get pulled in on init now also pull in another copy of the bootstrapper, which is redundant if the user has paket.bootstrapper.exe renamed in their solution/project root.

[vbfox]

@baronfel Ah yes I forgot about that feature :)

A lot of things can be solved with the main executable knowing (via an argument) that it was started from a bootstraper already. I'll add that to the PR.

[forki]

Do you think it's ready for alpha release? Can you please add a bit of docs?

[vbfox]

Yes I think it's ready. When merged the version in PaketRunner might need adjustment but that's all.

Regarding docs I documented it in the doc about bootstraper.
To avoid confusing users while it's still in test I didn't change the installation / getting started pages. Should I change them ? Maybe only installation with a warning that it's experimental ?

[forki]

thx I released it in alpha!

[forki]

can we get alpha versions of paket in magic mode?

[vbfox]

can we get alpha versions of paket in magic mode?

Yes you can but can't ask for "prerelease" in general you must specify a version for now. Even in magic mode the .config file is still supported for that, creating a paket.exe.config with :

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="PaketVersion" value="3.24.0-alpha002"/>
  </appSettings>
</configuration>

Will use the current alpha.

If the magic mode is really useful and used a lot I was thinking to move paket version specification in paket.dependencies using a very simple syntax known to the boostraper and that the main executable ignores like :

# bootstraper: 3.24 --prefer-nuget

source https://api.nuget.org/v3/index.json
nuget FAKE
nuget FSharp.Core ~> 4

[forki]

yes that would be awesome

[forki]

what I would need right now is a setting in appsettings that will take latest alpha

[pmiossec]

The end result is that the bootstraper paket.exe can be placed at the root of a repository avoiding the need of shell scripts, cmd scripts or even a .paket folder.

The "first time user" experience is also much better : place paket.exe in solution root then paket init. You can commit it, it's small and keep itself up-to-date.

Is it the recommended way to use it? Or is it advised to keep the bootstrapper, once renamed, in the .paket folder?
Because in this case the paket.targets does not work anymore :(

Or perhaps update the lines at the beginning of paket.targets file :

<PaketExePath Condition=" '$(PaketExePath)' == '' ">$(PaketToolsPath)..\paket.exe</PaketExePath>
<PaketExePath Condition="!Exists('$(PaketExePath)')">$(PaketToolsPath)paket.exe</PaketExePath>

to verify if we use it as "magic mode" otherwise, continue as usual... (solution tested and that seems to work)

[vbfox]

@pmiossec for now i'd recommend to keep it in .paket for compatibility.

Thanks for the .targets fix :)

As I like having paket.exe in the root i'll continue to fix small details in this mode but I don't know if it'll ever be the recommended / default way 😸 (Magic mode itself might become the recommended / default in v4)