fix packaging of FSharp.Core. #3452
Conversation
|
@matthid, |
|
@matthid we have not yet published a 4.1.X package from this repo. And master branch is quite a way ahead of the released FSharp.Core packages. Should I manually put together an updated package using already released binaries, or are you okay with waiting until we update the dotnet cli? |
|
To be honest I wasn't after an updated 4.1.X release, but I figured when I'm already at fixing this I can fix it there as well. So if we ever do another release it should contain the fix, but I'm ok with an updated 4.2.X release. So to answer your question I'm OK with waiting. This is not urgent, but it will be quite an annoyance when we forget it and people start using higher frameworks |
|
I will have to push a new release to align with VS2017.4 preview 1. Not being a PM I don't really know when that is, but shortly. Unfortunately the bits for it are already built, so I will have to manually make them ... well not really manually but you know what I mean. As for Net Standard 2.0 support. When F# moves to Net Standard 2.0 we will very likely deprecate F# support for NetStandard1.6, the experience we had with portable profiles encourages us to never go there again. There will be a Desktop and NetStandard 2.0 library. Anyone who wants NetStandard 1.6 will use the final shipped 4.2.* library. I do not have a date for when we will make this change to F#, it depends on schedules ... Right now we can't make that change because the DotNet cli 1.1.1 and VS 2017.3 still rely on NetCore 1.X, and we have no way to pre-req dotnet cli 2.0. My current expectation is that we will move F# over to NetStandard 2.0 only before the end of this year. |
|
@matthid Apparently it will be VS2017.4 Preview .2. That's the next update to F# |
|
In terms of .NET Standard support: .NET Core 1.1 and .NET Standard 1.6 are supported for one year as of August 14th. Whether or not we make a change towards .NET Standard 2.0 during that time frame is unknown, but we will not be deprecating the FSharp.Core release that targets .NET Standard 1.6 until at least a year from now. |
|
Ok I see what you are saying, if 2017.4 preview 2 contains this fix that would be nice (if I got that correctly). About the netstandard20 thing:
|
|
@matthid Yep that is the goal. There is no good reason to continue re-packaging the old dll in newer and newer packages. Just referencing the specific package you need should be sufficient to acquire the dll that is needed by the build. Kevin |
|
@KevinRansom it's not. The problem is that the rest of the world moves on and wants to build for old and new platforms. We don't live in isolation. Current situation means other packages can only build for old platforms or new platforms. But only with very very hard work against all. |
|
Sorry for being so short here. It's late. Will try to explain in more depth tomorrow. |
|
I think the project file would like this, which doesn't seem very terrible. |
Yep, and ironically NuGet/dotnet-sdk is now in the same situation as Paket, to require different versions for different platforms is just not how NuGet was designed to work. That's the hole reason why they support multiple platforms in a SINGLE package. Idea is that you add platforms, not remove them. But right now I'm not even suggesting that. Can we somehow test how #3454 would behave technically? Is a prerelease something we can achieve and test with? Maybe I test this on AppVeyor and report back, though thoughts about it are very welcome. |
@KevinRansom We don't say it isn't possible, we say that it is hard. And managing multiple versions is hard. Does pack generate the correct nupkg (ie correct versions in correct framework groups)? Is this really worth breaking pakets unification logic? Generally NuGet packages should support more platforms the lower they are in the dependency tree. Requiring multiple versions on a consumer side makes it very hard to think about your dependencies and debug issues, we are really opening a can of worms here. |
|
@Kev are we supposed to find such hacks for every package? Or only
fsharp.core?
Am 17.08.2017 10:43 nachm. schrieb "Matthias Dittrich" <
[email protected]>:
Current situation means other packages can only build for old platforms or
new platforms. But only with very very hard work against all.
Yep, and ironically NuGet/dotnet-sdk is now in the same situation as Paket,
to require different versions for different platforms is just not how NuGet
was designed to work. That's the hole reason why they support multiple
platforms in a SINGLE package. Idea is that you add platforms, not remove
them.
Note that I'm not saying that there is no point when you remove them again
- just that we should think about how it hurts us to distribute OLD
binaries with newer packages. If it's a customer communication problem we
need to find a solution for that.
But right now I'm not even suggesting that. Can we somehow test how #3454
<#3454> would behave
technically? Is a prerelease something we can achieve and test with? Maybe
I test this on AppVeyor and report back, though thoughts about it are very
welcome.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3452 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADgNAz8QkdzYgZQRDJrc3bQYFJu3Ze1ks5sZKYCgaJpZM4O6oq8>
.
|
|
Sorry for snark. It's too late. Tomorrow... |
|
@forki ... dood, that's not snark ... you should see how my kids talk to me .... now that's snark :-) |
* Document project options and mark lots of things as deprecated (#3449) * Document project options and mark lots of things as deprecated * delete some code that is no longer used * fix packaging of FSharp.Core. (#3452) * implement IDisposable interfaces explicitly (#3447) * added IDisposable * reverted Dispose change * ngen open source install (#3456) * handle "Blue (high contrast)" theme (#3443)
|
I seem to have forgotten, why is providing an FSharp.Core for Net Standard 2.0 important? Since the NetStandard 1.6 one will work everywhere that the NetStandard 2.0 version will, and we don't require any new APIs? |
|
@KevinRansom it's about user experience. One of the selling points of v2 is that you no longer need to download a mass of packages. A lot of work went into this. Problem is F# projects cannot participate as long as we have no empty netstandard20 in the package (NuGet/Paket have no choice but to download all deps) We know that this cannot happen over night and you will have some packages depending on netstandard16 packages. But FSharp.Core is the most important package that needs this change and it needs it first if we want to participate otherwise this BLOCKS ALL F# library authors to make their customers benefit from this. |
|
I agree with @matthid that the experience there would be kind of lame: downloading the package graph for netstandard1.6 if I'm only doing 2.x stuff is a bit much. I expect the "takeover" of 2.0 to be quite rapid, do I'm certainly not opposed to getting a netstandard2.0-based FSharp.Core out there. Does revving a new version of FSharp.Core right now seem "right" to you right now @matthid @forki? |
Can you elaborate what that even means? All I'm suggesting is to add the NuGet dependency group (if that works technically) or to ADD another binary. Note that I'm already trying to find a solution which is working for you but we cannot meet anywhere if I don't understand why you think it is so important to have only a single binary (ie start a new version without 1.6 support) |
|
In general we can say that it is very important for core components to be the first to support something and to be the last that keeps support for something old. If we don't maintain this (somewhat annoying) strategy in core components than the rest of ecosystem will have a hard time.
By removing support for older netxx frameworks we forced people to create weird undocumented semiworking constructions that reference different versions of the FSharp.Core package. And there is no tool support because we would need to special case things.
For netcore2 we have a different situation. Technically everything is working fine. Using netcore16 means we only use a subset and that's a good thing. But not proving explicit netcore2 support defeats the whole purpose of netcore2. One basic idea was to get rid of the many many small packages that are together building the .NET framework and use a small numbers of larger packages.
By only providing netcore16 users can already work fine with netcore2 world since its compatible. But we still force them to reference the full netcore16 universe. And since fsharp.core is so central this means all F# projects will always references and download this huge dependency graph. And nobody has a chance to opt out. There are no small projects anymore. Hello world projects now download hundreds of MBs of unused dependencies. That's really a shame.
Part of this problem is that the nupkg format is really bad and the nuget team never bothered to think about making it better. But this we can't change.
So we suggest the following:
a) add a simple group to the nuspec that just says "for netcore2 we have different deps"
b) if a) alone is not working then we should add a second lib and a new nuspec group.
Even with b) and increased package size the overall download size will go down dramatically in netcore2 scenarios. At least once more and more packages are joining this train. If a) alone would work then this would be a cheap win. So we should definitely try that first.
|
|
@forki My preference is to only ship a NetStandard1.6 assembly for ever ... since it works in the most places. NetStandard 2.0 works in all of the same places. And so does NetStandard 2.0. As for the dependency download I'm sort of in the who cares bucket about that because:
We can certainly build and ship netstandard1.6 and netstandard2.0 and presumably netstandard 2.1, 3.0, 4.0 blah blah blah specific versions of FSharp.Core. However ... that wasn't that straightforward with portable libs before and doesn't really gain us any platform reach and increases the download size of the FSharp.Core package for every developer. So specifically and technically why is NetStandard 1.6 a bad thing, why is caching the download problematic? I think not specifically defining the packages netcore 2.0 dependencies and opportunistically relying on the dependencies of other referenced packages to find the framework references is flat wrong. And in someways is reminiscent of the ambient F# core versioning issues that we have always had. |
But what of people building .NET Standard 2.0 libraries. For example, pretty much all of MBrace or Akka.NET or the like?
It feels like 1.6 --> 2.0 is qualitatively very different, basically a reset of the ecosystem.
My understanding is that it is because it exposes all users of the library (including those just doing .NET Standard 2.0+ library development) to pre-.NETStandard 2.0 "many small packages" framework, and there's no way for users to avoid that. This kind of makes it feel like F# is behind-the-times, keeping the user tied to heavy ways of engineering |
|
The whole thing has nothing to do with the compiler. It's only what the
package resolver (nuget or paket) is doing
|
No, basically they changed with netstandard20 how this stuff works. Now you can always assume that when you are on netstandard20 that all APIs are available on the target runtime for this Standard (which is a sane assumption). This means the SDK will add the NetStandard.Library package IMPLICITLY, this package will then have all the reference assemblies required for compilation. But you no longer need EXPLICIT dependencies for packages already in the standard. (Note: This might not be completely technically accurate...) |
|
Or in other words: There is no longer a "half" standard, either a runtime implements the complete standard and stuff works or not. Basically FSharp.Core currently specifies a "part" of the netstandard16 which it depends on, this is now no longer required and implicit. At least that is my understanding of this stuff. |
|
Yes @dsyme. Netstandard 2 is yet another reboot. That's exactly the point.
People understood that DNX did not work without fundamentally changing
package format and package managers and tree shakers and linkers.
It's a new chance to get rid of all the accumulated issues that blocked the
ecosystem for the recent years.
Bit only if all core components play the same game. If only one component
is referencing older netstandard then everything falls apart.
Am 18.08.2017 7:05 nachm. schrieb "Steffen Forkmann" <[email protected]>:
… The whole thing has nothing to do with the compiler. It's only what the
package resolver (nuget or paket) is doing
Am 18.08.2017 6:49 nachm. schrieb "Kevin Ransom (msft)" <
***@***.***>:
> @forki <https://github.com/forki>
> how will empty deps work for compilation or deployment for that matter?
> Unless you are hoping that the compiler will happily find the references
> from some other dependency and so opportunistically work.
>
> My preference is to only ship a NetStandard1.6 assembly for ever ...
> since it works in the most places. NetStandard 2.0 works in all of the same
> places. And so does NetStandard 2.0.
>
> As for the dependency download I'm sort of in the who cares bucket about
> that because:
>
> 1. Anyone building an app will use netcoreapp2.0 which is also a
> bunch of contract assemblies and so is to use your phrase a huge graph.
> therefore any developer who needs to deploy and test her app on netcore
> will need to download and deploy that huge graph.
> 2. Nuget and, I presume, paket can and should cache the download
> making it a one time cost.
>
> We can certainly build and ship netstandard1.6 and netstandard2.0 and
> presumably netstandard 2.1, 3.0, 4.0 blah blah blah specific versions of
> FSharp.Core. However ... that wasn't that straightforward with portable
> libs before and doesn't really gain us any platform reach and increases the
> download size of the FSharp.Core package for every developer.
>
> So specifically and technically why is NetStandard 1.6 a bad thing, why
> is caching the download problematic?
>
> I think not specifically defining the packages netcore 2.0 dependencies
> and opportunistically relying on the dependencies of other referenced
> packages to find the framework references is flat wrong. And in someways is
> reminiscent of the ambient F# core versioning issues that we have always
> had.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#3452 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AADgNBoiw147Ro0422W82TVAwjdhiw0oks5sZcC2gaJpZM4O6oq8>
> .
>
|
|
Can anyone here help with this similar bug fscheck/FsCheck#410 ? In this case, the nuspec file is generated from a paket.template file |
* Document project options and mark lots of things as deprecated (dotnet#3449) * Document project options and mark lots of things as deprecated * delete some code that is no longer used * fix packaging of FSharp.Core. (dotnet#3452) * implement IDisposable interfaces explicitly (dotnet#3447) * added IDisposable * reverted Dispose change * ngen open source install (dotnet#3456) * handle "Blue (high contrast)" theme (dotnet#3443)
7 participants
See #3451