Paket netcore/msbuild15 - no nuget needed

[cloudRoutine]

We're pretty close to the point where we won't need to rely on nuget for any part of the netcore, restore, build, pack, and publish process.

Remaining Features

( WIP - I'll fill out the list with items and references as I investigate everything we'll need)

• paket pack intercepts and edits nuspec

• generate nuspec from project file - Create .nuspec files from project file #2211

• enable paket.template usage with pack target

• generate lockfile project.assets.json

  • LockFileBuilder.cs the actual project.assets.json file
  • Nuget RestoreCommand.cs
  • RestoreTargetGraph.cs

• generate nuget.g.props & nuget.g.targets

  • BuildAssetsUtils.cs - GenerateMsbuildOutputFile
  • MSBuildOutputFile.cs
  • MSBuildRestoreItemGroup.cs

Open Questions

• should we wrap everything up in a Paket.Sdk?
• should there be default dirs or a default layout so that paket.templates and similar things are automatically pulled into the build process?

cc @forki @baronfel @enricosada @smoothdeveloper

[forki]

Will we have a version that does not need mono?

/cc @matthid

[matthid]

Sorry to disturb a bit but how is "generate nuger.g.targets" the same as "won't rely on nuget"

@forki yes we could have build that ever since I did the huge coreclr branch. I was just lazy and only needed the nuget package :P

[forki]

The dependency on mono is one of the reasons why @alfonsogcnunez is not keen on using it in fable templates. Am 15.04.2017 3:41 nachm. schrieb "Matthias Dittrich" < notifications@github.com>:

…

Sorry to disturb a bit but how is "generate nuger.g.targets" the same as "won't rely on nuget" @forki <https://github.com/forki> yes we could have build that ever since I did the huge coreclr branch. I was just lazy and only needed the nuget package :P — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2249 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNFJ9zvJAr-URKtFOzKc2PTqm1gNqks5rwMj7gaJpZM4M9Tc6> .

[matthid]

making a dotnet standalone tool should be really straightforward at this point... I don't think any big code changes are needed (if at all).

more interesting is the bootstrapper or the distribution as then the package either requires an installed sdk/runtime or depends on a specific platform...

[cloudRoutine]

@matthid nuget creates those resources during restore that msbuild15 needs to compile a project, that's the main role it's still playing in the build process

[matthid]

@cloudRoutine I know (therefore the sorry) it just still feels wrong ;)

[forki]

Yes bootstrapper is the hardest part. I hope someone will contribute a black magic mode. Am 15.04.2017 15:52 schrieb "Matthias Dittrich" <notifications@github.com>:

…

@cloudRoutine <https://github.com/cloudRoutine> I know (therefore the sorry) it just still feels wrong ;) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2249 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNLXSIQmmjaKW7qvLIz1A8IrXFDHMks5rwMulgaJpZM4M9Tc6> .

[cloudRoutine]

am I missing something? what's hard about the bootstrapper? paket is a dev tool, so whoever is using it will have the sdk installed already. It's not like we worry about whether someone has installed netframework on their windows machine, because paket will be useless if they don't 😜

[enricosada]

@forki boostrapper Is in #2125

It doesn't use dotnet cli tool, just paket.dll (paket published as fdd) inside a nupkg.
Dotnetcli tool is not needed ihmo and had drawbacks

Pratically at first restore, it restore the package who contains paket

[matthid]

It's not like we worry about whether someone has installed netframework on their windows machine, because paket will be useless if they don't 😜

yes we do, otherwise we wouldn't mind installing mono :/

[enricosada]

As a note.
We should not fight but integrate and open extension point of needed.
No need to replace whole pack sdk. It's going to be harder and more corner cases.

The only big issue I see ATM is having Sdk (the sdk attribute) so paket target exists before proj restore ( no need to custom import )
But that require something is wip atm

[matthid]

Pratically at first restore, it restore the package who contains paket

so you still need nuget to restore paket? :/

[enricosada]

yes we do, otherwise we wouldn't mind installing mono :/

If we restore like mine or with published paket (netcoreapp + net45) will work with mono, netcore and full fw.
Like FSC does. It switch FSC based on msbuild host. With msbuild.exe use fsc.exe, with dotnet mabuild use FSC netcore

[enricosada]

so you still need nuget to restore paket? :/

Yes. But who care? When sdk attribute will be extensible by custom sdk, will work like that, but no need ogni custom import

[enricosada]

To boostrap we can also call something else ( webclient.download) to restore the nupkg or a zip, instead of nuget sdk.
But who care?

[cloudRoutine]

@matthid and I do since we're working toward a no msbuild, no nuget, no fsproj, build pipeline

[matthid]

We should not fight but integrate and open extension point of needed.

I'm not trying to fight just arguing in another direction. Sorry if I sounded harsh.

My argument is that we contradict ouself if we argue that we don't want to have mono installed but really just switch one dependency with another...

[forki]

I want it to work on both. A mono version and a dotnet version. That's what I meant with back magic mode. Am 15.04.2017 4:14 nachm. schrieb "Matthias Dittrich" < notifications@github.com>:

…

We should not fight but integrate and open extension point of needed. I'm not trying to fight just arguing in another direction. Sorry if I sounded harsh. My argument is that we contradict ouself if we argue that we don't want to have mono installed but really just switch one dependency with another... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2249 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADgNLxDHsQrTxy7Q2T249fCCtMIFOxZks5rwNC-gaJpZM4M9Tc6> .

[cloudRoutine]

@matthid you mean switching mono for netcore?

[matthid]

@cloudRoutine yeah. the only fundamental advantage is that we can build a standalone tool (with the runtime included) with dotnetcore. But maybe I'm completely alone with this opinion (at least it seems like this).

[enricosada]

You don't need to choose mono over dotnetcore.
Just use the same runtime msbuild is using.
Msbuild is Core? Run dotnet paket.dll
Msbuild is Mono? Run mono paket.exe
Msbuild is Full? Run paket.exe

That's similar to how FSC is doing

[cloudRoutine]

@matthid there are some contexts where I think that will be useful for stuff I'd like to do with paket and FAKE, but I don't expect to be using the runtime specific standalone versions during normal dev over an fdd version.

[enricosada]

Closing.

.net core only paket is tracked in #2875 (with notes about .net sdk too)