Embedding Paket into the template

[theimowski]

When #101 is ready, this would mean no longer dependency on full .NET / Mono

fsprojects/Paket#3183

[isaacabraham]

Does this mean no more mono is now needed?

[theimowski]

Yes, when paket works on .net core

[theimowski]

Paket 5.182.0-alpha001 comes with full .net core support - I'll start testing it with SAFE template

[theimowski]

@matthid when invoking fake as global tool it uses paket to restore the packages - does it look for paket in path? Does it mean that if you have paket installed as global tool, SAFE template doesn't need to provide a paket bootstrapper anymore?

[matthid]

@theimowski no. fake references paket.core and has no dependency on paket.exe

[theimowski]

Doh, right I forgot about that! This actually means that SAFE template doesn't have any dependency on Paket to spin up the template - we can just remove .paket/paket.exe (magic bootstrapper) completely. Then it's up to the user how one wants to call paket.
Or is there something I'm missing?

[theimowski]

So seems current situation is that thanks to FAKE 5, SAFE Template doesn't really need to bundle paket / paket.bootstrapper.
The question is whether we want to remove it altogether and let users choose their way of incorporating Paket into the project, or do we want to emphasise a solution, ideally based on .net core build of Paket?
I'm interested what people say @isaacabraham @forki @Krzysztof-Cieslak

[isaacabraham]

As I understand it - if you use FAKE as a global tool, then it just downloads the paket.core assembly and calls restore on that instead shelling out to the paket exe - is that right? I've no problem with this - it seems clean to me. The only questions are:

1. Global FAKE is needed I guess? (Not a problem really - same for npm / yarn etc.)
2. Is there anything we lose with this approach? I suppose you can't just call paket restore directly now, you have to go via FAKE - that's something that could be annoying. How would this impact in Ionide with the Paket extension?

Anything that simplifies the number of moving parts is a good thing, as long as we're not losing out anywhere.

[theimowski]

Yes, global FAKE is needed - that's what we have in the prerequisites already.
What we lose with this approach is that we'd require the user to know how to deal with paket dependencies himself - one will no longer have the bootstrapper. But for the initial fake build there's no difference

[isaacabraham]

So how does one update their paket dependencies - adding a new package etc.?

[matthid]

@isaacabraham

if you use FAKE as a global tool, then it just downloads the paket.core assembly and calls restore on that instead shelling out to the paket exe - is that right?

Not completely accurate. Paket.Core is part of every fake 5 installation. The Fake-Runtime will download the modules (=nuget packages) before executing the script. This process basically contains a paket restore when using the "external" paket.dependencies fake 5 feature.

Note this is basically a special feature / improved integration of the "external" paket.dependencies feature of fake 5. With "paket-inline" no global restore is done and fake will ignore the external paket.dependencies file.

I suppose you can't just call paket restore directly now, you have to go via FAKE

Why not?

[isaacabraham]

If the .paket folder is longer available, how do people call Paket?

[theimowski]

We discussed this a bit, and for now we want to wait until Paket as global dotnet tool gets stable. Then we can simply suggest users to use that and remove Mono / full .Net from prerequisites

[theimowski]

Ok so as of now Paket dotnet tool is no longer in alpha - this means that we can remove paket bootstrapper from template and instruct people to use Paket as global tool

[forki]

the problem is still with proxies. someone needs to fix that for netcore

@enricosada

[theimowski]

right I see, and what about Paket.Restore.targets - should it be still under source control, or can we remove it as well?

[forki]

targets file should be committed

[Krzysztof-Cieslak]

Sooo... is the global tool a Paket or Paket bootstrapper( in magic mode). How do you control version with global tool? Do you expect users to update global tool as often as Paket is released (every 3 hours ;-) )?

[enricosada]

@Krzysztof-Cieslak i already implemententend these points, see https://github.com/enricosada/paket-netcore-testing-as-tool

it will install the paket.bootstrapper, if not installled, and run that, like now.
so will respect paket.exe.config (for pinned version) or the version in paket.dependencies.

bootstrapp another time is a noop

If you just need to pin the version, you can also skip paket.bootstrapper and just configure it to install paket tool (but you lose download from github, but nayway for a single package is fast).

[enricosada]

@theimowski just proxy atm it's the only issue i know.
The rest works, and flow should be ok, while maitaining all the paket features.

the scenario 2 show a dotnet build from fresh clone.

About the target file, yes, need to be committed in the repo.
To improve that:

• is possibile to split restore and pack targets. pack targets doesnt need to be there, because can be loaded by an import, so file will be smaller
• implement a different import mechanism, i have an idea how to do that, but first paket need to be .net core (that is already using my free time)

[theimowski]

Ok then from template POV let's wait until proxy issue is solved in Paket as dotnet tool

[theimowski]

Decided to remove paket.exe #232 binary from template contents - thanks to embedded Paket in FAKE one can restore packages using only FAKE dotnet tool. In docs we changed a dependency on Full .NET / mono to an optional dependency on Paket - i.e. if someone needs to manipulate packages then needs to install Paket - but we don't force any specific solution for now

[theimowski]

Reopening - there's an issue if someone needs to run dotnet restore on a freshly created project as it looks for .paket/paket.exe Currently one needs to do fake build before so that next time dotnet restore is called paket cache is used

[theimowski]

Fixed by #241

[MangelMaxime]

Hello,

in order to reproduce an issue from Zaid, I had to use SAFE template and install a new library in it Elmish.SweetAlert so I edited the paket files as asked in the SAFE docs.

But now, how do I run paket update?

Also, if I run dotnet restore after editing the paket files, it fails.

Step to reproduce:

1. dotnet new SAFE --js-deps yarn
2. fake build --target run
3. Check that dotnet restore works
4. Edit paket.dependencies and src/Client/paket.references to add Elmish.SweetAlert
5. dotnet restore src/Client ?

And now I have this error:

  /var/folders/zl/k6t613xj1h94f6w6r4shdsx40000gn/T/tmpe8846ec0e3e54ce4a1f3eae82f8ba350.exec.cmd: line 2: paket: command not found
/Users/maximemangel/Workspaces/Tests/testFemtoYarnBug2/.paket/Paket.Restore.targets(186,5): error MSB3073: The command ""paket" restore --project "/Users/maximemangel/Workspaces/Tests/testFemtoYarnBug2/src/Client/Client.fsproj" --output-path "obj" --target-framework "netstandard2.0"" exited with code 127. [/Users/maximemangel/Workspaces/Tests/testFemtoYarnBug2/src/Client/Client.fsproj]

[kerams]

@MangelMaxime I add dependencies like this

paket add -g Client --project src\Client\Client.fsproj Elmish.SweetAlert

Restore after that seems to work fine too.

[MangelMaxime]

So, it's probably expected that we install paket as a global tool, if we want to use it.

If, yes I think https://safe-stack.github.io/docs/quickstart/ should be modified.

Instead of

Paket (optional*)

I propose something like

Paket installed as global tool (dotnet tool install -g paket-cli) (optional*)

Note the CLI is probably wrong it just for the example

[theimowski]

We already have following in quickstart docs:

• Paket (optional*)
• ...

* You don't need Paket if you just want to try out SAFE. However if you need to edit NuGet dependencies you can read docs on how to get started with Paket.

Isn't that enough?

[MangelMaxime]

Isn't that enough?

For me no, because I read the documentation and got stuck. Perhaps, because I know that paket is working in the repo but not exposed (FAKE is doing the restoration job for us if I understood correctly).

I disagree a bit with this statement:

You don't need Paket if you just want to try out SAFE

I understand why you say that. You say it because indeed to run the template out the box it's not needed.

But because this is a template people will "always"/often want to modify the dependencies at some point unless the template is matching 100% of their needs (spoiler no template does that ^^). You will always want to upgrade to latest or add a new deps :)

I think that if your documentation, made paket a requirement even if the user doesn't use it. It would solve the situation here because the user can easily invoke paket.

All of that is just a proposition, I think both positions have pros and cons. But, I wanted to share my experience with the template/docs as this is the first time I install it as a user.

[theimowski]

Right, I can see your point. Would you be willing to submit a PR with that change to https://github.com/safe-Stack/docs?