(re-) implement Paket Task about vsts-fsharp

[isaacabraham]

Better to improve the existing one than have two surely?

• "replace the bootstrapper" - what does this mean?
• cache paket on agent - this will probably be difficult (impossible?) to do since as far as I'm aware there's no way to keep the same physical agent across builds / releases. The only way to do this as far as I know (and we've done this) is to host our own VM and install the ADO build agent on it.
• credential manager - that would be great - integrating that into the main task and just have it run "automatically" would be way better than having multiple tasks.

[matthid]

"replace the bootstrapper" - what does this mean?

It means the task doesn't run the bootstrapper on the agent because the task is downloading paket

cache paket on agent - this will probably be difficult (impossible?) to do since as far as I'm aware there's no way to keep the same physical agent across builds / releases.

While that is true, there is a task library api to cache tools between runs, maybe they use it for internal optimizations. But it definitely optimizes the scenario where you run your own agents.

that would be great - integrating that into the main task and just have it run "automatically" would be way better than having multiple tasks.

Yep that one is probably a no-brainer.

However, is investing the time worth it? What I have noticed is that the fake-task is already enough for the general use-case. It already does setup everything and you don't really need any paket task at all.

[isaacabraham]

It means the task doesn't run the bootstrapper on the agent because the task is downloading paket

Nice to have this feature but is it really needed - with magic mode you just replace the bootstrapper to paket.exe anyway?

While that is true, there is a task library api to cache tools between runs, maybe they use it for internal optimizations. But it definitely optimizes the scenario where you run your own agents.

When you run your own agent paket is cached on the machine anyway, so it just works.

However, is investing the time worth it? What I have noticed is that the fake-task is already enough for the general use-case. It already does setup everything and you don't really need any paket task at all.

What about people that don't use FAKE at all and just want to use Paket in isolation - I think having the separation and ability to choose one or the other is a good thing. Of course, we could also just say that if you use FAKE, then you don't need the Paket task at all?

[matthid]

What about people that don't use FAKE at all and just want to use Paket in isolation

Yep even in those scenarios I'm not sure a separate task gives any advantages: As paket is integrated in the dotnet build process you can just use the "setup paket credential manager" task and run dotnet build, why add another task if you might need the "setup" task anyway? So we are only really tasking about legacy project format then...