search

fsharp / fslang-design

RFCs and docs related to the F# language design process, see https://github.com/fsharp/fslang-suggestions to submit ideas
510 stars 142 forks source link

[F# Tooling RFC FST-1001] Discussion: FSharp.Core delivery via nuget packages #197

Closed dsyme closed 6 years ago

dsyme commented 7 years ago

Discussion thread for F# Tooling RFC FST-1001: FSharp.Core delivery via nuget packages. Please contribute to the discussion and send PRs to edit the document itself. A couple of reminders

And a reminder that this is an F# Software Foundation design repo brought to you by the F# Core Engineering group.

Thanks! Don

dsyme commented 7 years ago

@nosami @migueldeicaza We'd appreciate input from the Mono/Xamarin perspective on this, thanks

dsyme commented 7 years ago

Feedback from @haf here https://gist.github.com/haf/eb9735a9cc75c5af5421c903884e5e71

matthid commented 7 years ago

I think in F# world we need to watch out for a lot more than NuGet compat. And that's an issue throughout at the moment. Most F# people use Paket but still we say "F# supports NetCore" while Paket doesn't. That's wrong. The same is true for this issue.

We really need to solve the problem that Microsoft seems to have with the FSharp.Core package especially The package is not easily buildable from a source-tarball (a requirement in some settings). IMHO this is the only long term solution. Doing the same mistake as we did with Microsoft.FSharp.Core.netcore doesn't help.

About The package is now relatively large (68MB on disk unzipped) due to the large number of variations, and may get bigger (E.g. embedded PDBs) this feels like falling into the same trap as .sigdata and .optdata but this time it's only the development machine and not the final deployment. And you could even argue that it's a nuget problem because there is no reason to extract stuff we don't need. (Don't cite me on that, NuGet is already complex enough...)

Sorry but I don't think it's the right way going forward. Only because it might be technically feasable to emty out the netstandard folder in the FSharp.Core package and add a reference to another package doesn't make it right. It's fundamentally flawed in any way you can think about packages.

matthid commented 7 years ago

It's not the compiler. Adding 100MB to the on-disk install size of the .NET SDK is a big deal.

(leaving compat and other concerns aside) Is it possible to split up FSharp.Core into separate package where one has some fundamental implementations required by the compiler (like casting and typeof operations where inline-il and magic is required) and a base library (which you can technically implement in pure F#)? Would that even help here by only requiring the fundamental package? This would be a correct split of the package (not along supported platforms but by features/apis).

Or do it as @haf suggested, initialize and download the package as needed...

dsyme commented 7 years ago

I personally suspect we will eventually (medium term) iterate to a single signed, small package with just a single .NET Standard DLL.

TBH we could almost just do that today in the next version of FSharp.Core nuget and the community would probably get over the hump. Even if that was expressed as an empty "FSharp.Core" that had a dependency on the (signed, Microsoft-provided) "FSharp.Core.netstandard". I don't think anyone would mind too much about that transitive dependency as long as you don't really notice it. Or Microsoft could just publish the "FSharp.Core" containing that directly.

That path would raise issues for portable, xamarin and .NET Framework. But those feel like "point in time" problems. The point of the RFC is to get all this out in the open so we can actually make sensible decisions. We would certainly need to look very closely at the exact technical differences between the .NET Standard and .NET Framework FSharp.Core.

enricosada commented 7 years ago

👎

Use fsharp.core nuget. nuget package support multi framework. This is just a politc mess who is gonna hurt library authors and user.

I want to quote a recent @migueldeicaza (i hope is ok to do it :P):

My take as a platform vendor: never abandon users, never break their code. Earn and keep their trust - I serve at the pleasure of my users

So please do the right thing, complicate the workflow to publish FSharp.Core nupkg as needed BUT make it easier for consumer to use it as normal library. Consumers (developers) doesnt need to handle politcis and mess from maintainers side. that's OUR job to make it lovely to use

What library (F# core is a library, but is required to compile) does something like that in .NET? Zero.

Library, not tool (i known csc package exists .netcore for space size? /cc @terrajobst @jaredpar) but is unzipped and bundled, dev doesnt see that in transitive deps.

The dotnet SDK takes a dependency on the existing versions of the FSharp.Core package.

  • The package is not signed

=> sign it. FSharp.Core already bundle SIGNED assemblies (like in netstandard1.6). => package signing doesnt exists. assemblies can be signed. so package can be composed (like now)

  • The package is now relatively large (68MB on disk unzipped) due to the large number of variations, and may get bigger (E.g. embedded PDBs)

=> see nuget cache. is not a problem this. there are not lot of versions anyway. => drop unused in next major (5.x) or minor (4.2). use trimmed 4.2 for sdk 2.0

  • The package was prepared and pushed in an adhoc way

=> there is a build script for that. push to nuget may be automated easy. or send to be signed. Is that different the other way?

  • The package contains some delay-signed DLLs (the Xamarin variations are delay-signed)
  • The package is not pre-installed with tooling (preventing some offline development scenarios).

=> bundle fsharp.core. Or download in local nuget cache or offline cache at first usage (like dotnet/cli does)

  • The package is not easily buildable from a source-tarball (a requirement in some settings)

=> really? is a zip file. how other nuget packages are built? how these source-tarball are built for other .net packages? Why cannot be done but for another package can?

I am adding Newtonsoft.Json example. Used everywhere in MS, but not owned by MS.

So ask FSF for shared ownership. Somebody asked @mathias-brandewinder or @ReedCopsey or FSF board about collaboration? if not, why? Add a step to sign it if you want. Is just an ownership issue, from maintainer side.

You can build FSharp.Core nuget INSIDE microsoft/fsharp if you want to speed up, and sign assemblies.

Dont let Conway law mess this please.

Bad scenario:

If you create a metapackage (and reference fsharp.core.netstandard) you CANNOT overlap target frameworks (otherwise two fsharp.core.dll). So is not like you can add fsharp.core.net40 easy. And after that is done forever for that major version. If ppl reference only fsharp.core.netstandard, and NEXT version of fsharp.core drop it, you cannot anyway mix the two. is bad for evolution.

So:

forki commented 7 years ago

I'm actually not that pessimistic. We can work this out here. As we have said multiple times the Microsoft netcore package was a big mistake and we should have avoided that completely. I'm really happy that Microsoft (don) now created a RFC to fix this problem and to restore trust. I think most of the issues mentioned above are not really practical issues. Some sound more like excuses, but maybe I'm wrong. Anyways I think everything boils down to the fact of ownership of fsharp.core package. And we have told many times I'm fine with transfer of ownership IFF Microsoft keeps support from for mono. Shared ownership like Enrico suggested would even be better and a clear sign by Microsoft that it trusts its community.

One final comment: FSharp.Core needs to be the goto package and we as community need to figure out how we do it. Microsoft.* packages would really be a bad sign and kill all that nice collaboration with that we built recently.

cartermp commented 7 years ago

Just to be clear (in case anyone thinks this is not the case):

The proposal is to make the FSharp.Core package the package to use. We do no wish to have a split in packages as a long-term goal. There may be a short period of time where there are two packages while technical issues get worked out, but the long-term goal is not to have a package split. Library authors should not have to change the package they depend on.

7sharp9 commented 7 years ago

Reading the RFC its not clear at all.

kurtschelfthout commented 7 years ago

I am worried about multiple packages and some of the proposed "NuGet hacks". FsCheck currently supports .NET, 3 PCL profiles, and .net standard. This needs a lot of care - I spend most of my time trying to get the thing packaged. All the subtle differences - like needing to target and depend on different packages - in practice cause a lot of lost time, and duplicate information everywhere. Honestly, .NET at this point is a giant hamster wheel for OSS maintainers. Anything you can do to reduce churn, please do.

I understand some of the concerns raised with the size of the package, but at the same time am not convinced by them.

E.g. the empty dependency etc sounds like a nice hack in theory, but in practice because of the unusual setup we'll be exposed to "user errors", bugs (from nuget to project system), and unusual (or at least they'll be branded as such) usage scenarios. This is insidious because the pain is spread out (the particular library author who's package is not working because of FSharp.Core dependency problems will get the error report) and so it takes some time before this rises to the overall group-consciousness. (I already see this with assembly redirects for FSharp.Core, by the way. Don't get me started on signed assemblies ;) )

KevinRansom commented 7 years ago

In many ways ... this would be easier if we just stated what scenarios needed to work. There are many ways to solve every problem, and we have probably used many of them over time on many projects.

If we can narrow down on the scenarios then we can worry about how, and which approach is superior.

These are the scenarios that I believe need to be addressed:

  1. VS developer needs to be able upgrade her existing VS2015 projects to the latest VS and have them work.

    • The VS same developer needs to be able to share projects and solutions with a co-worker using an earlier version of VS.

    • The VS team use a build server to build their project on a daily basis. They don't want to buy a licence for Full VS for the build server.

  2. Developer builds a new desktop library to extend an existing F# application, the existing F# application targets FSharp 3.1 using the F# 4.3.0.0 FSharp.Core and the VS 2017. She needs to amend the existing APP and build the new library.

  3. Developer is building a library on the Windows Desktop that targets Win 8.1, Xamarin iOS and the Windows Phone (Well .... there may be someone)

  4. Using VS a developer builds a new application targeting dotnetcore1.0.

  5. Using VS a developer builds a new application targeting dotnetcore2.0.

  6. Using any editor on supported OSs and the dotnet sdk a developer builds, tests and deploys a new application targeting dotnetcore1.0.

  7. Using any editor on supported OSs and the dotnet sdk a developer builds, tests and deploys a new application targeting dotnetcore2.0.

  8. Using any editor on a Windows PC a developer builds, tests and deploys a new application/library targeting net46.

For now this is my list, I'm sure there are more but you see how it goes ... they are development activities associated with F#. They mention pre-requisites for the scenario (Windows, VS, Supported OS that kind of thing) They don't say how to accomplish it. Indeed they don't even mention nuget yet.

kurtschelfthout commented 7 years ago

@cartermp

There may be a short period of time where there are two packages while technical issues get worked out, but the long-term goal is not to have a package split.

Honestly, that sounds worse than "just" a split. Because now I can look forward to splitting issues, and then in the "long term" to merging issues.

forki commented 7 years ago

Kevin I have to disagree. VS is not the driver. VS needs to follow whatever the community does. The "VS first" approach brought us into this mess.

That said of course we want to make it easy for VS users.

But currently basically all F# projects I know use the FSharp.Core package. Tbh I don't remember a single project in OSS or commercial that really uses the shipped fsproj template with Reference Assemblies fsharp.core. It's just wrong. Let's pleases focus on ecosystem experiences. VS being one part of this.

cartermp commented 7 years ago

@kurtschelfthout

Honestly, that sounds worse than "just" a split. Because now I can look forward to splitting issues, and then in the "long term" to merging issues.

That's a fair concern. But please do note that we are on a tight schedule here, and must deliver on F# support for .NET Core 2.0 and .NET Standard 2.0. We feel that a failure to deliver on workable bits which meet our compliance requirements because we could not agree on which package to use for FSharp.Core with OSS package authors is a worse situation than a temporary split (or some FSharp.Core package magic under the covers) until issues get worked out. This is not an ideal situation, but it's the one we're in.

vasily-kirichenko commented 7 years ago

@forki The team is named "Visual F# team", not "F# team".

KevinRansom commented 7 years ago

@forki so ... I didn't notice that you have any scenarios to add ... can you please identify the scenarios that you have in mind.

The scenarios with prerequisites such as VS are vitally important to me, because existing customers need to be able to count on us to ensure that their existing projects and skills have a forward development path.

@kurtschelfthout I think @dsyme is presupposing a set of possible implementations. First let's figure out what needs to work.

forki commented 7 years ago

Philip you brought yourself into this mess by hijacking sdk (or not supporting f# sdk in the first place so that Enrico needed to step in) and releasing Microsoft netcore packages. The community fixed a lot of this for our own use. So you really need to give credit to what already exists and what your current users actually use. We all want to help you on this path but don't rush again and release yet another package that noone is actually using.

forki commented 7 years ago

Kevin your existing customers use the community package not the Reference Assemblies versions. Basically everyone I talked to switched to this eventually.

matthid commented 7 years ago

But please do note that we are on a tight schedule here, and must deliver on F# support for .NET Core 2.0 and .NET Standard 2.0. We feel that a failure to deliver on workable bits which meet our compliance requirements because we could not agree on which package to use for FSharp.Core with OSS package authors is a worse situation than a temporary split until issues get worked out. This is not an ideal situation, but it's the one we're in.

Tbh. I don't get it, we have this stuff worked out by @enricosada already. Just let's use that until we have figured it out?

matthid commented 7 years ago

And I'm not even sure people can tell the difference if F# is in the box or not as long as the entry points work (dotnet new -lang f#). Or do they?

KevinRansom commented 7 years ago

@forki well then we better make sure we do not break their projects then.

kurtschelfthout commented 7 years ago

Kevin your existing customers use the community package not the Reference Assemblies versions. Basically everyone I talked to switched to this eventually.

Exactly. The current FSharp.Core package works for everyone, except apparently MS internal. And it seems like most of the concerns can be addressed fairly easily? Like sign the dlls, ad hoc packaging etc. Why is a split even on the table at this point?

EDIT: sorry I'm more and more confused, and I'll stop commenting now :)

forki commented 7 years ago

Kurt as I said "it all boils down to ownership". It always is when Microsoft is in the boat.

enricosada commented 7 years ago

Maybe we can focus on trim the scope a bit, to focus on time for vf# and normal ?

new fsproj works with nuget as first class (like modern .net development). Issue is afaik, we need nuget package whichcan be bundled by MS (ownership/legal matter there, is ok) for:

Some points can be removed too ihmo (like unzipped package size), because is a matter of ownership atm (is ok, to be bundled legally in VS) so this optimization doesnt matter a lot now. can be discussed separately.

Can we start from existing and exclude possibilities, just to be sure?

  1. @KevinRansom is ok to exclude net40 packaging from this discussion? the FSharp.Core.netfx is really overllapping with FSharp.Core atm, if you add that in default template is bad (mixed old fsharp.core and new packages FSharp.Core.netfx, so two fsharp.core.dll). Is possible to use a <Reference like now for net40 templates? so is this exact VS2015/7 situation. Not optimal, but one worry less, to discuss at the end.

  2. use a <PackageReference Name="FSharp.Core"> in templates for netstandard/netcoreapp (implicit or explicit), like now dotnetcli. Merge signed assemblies in FSharp.Core like now.

    • pro: fsharp.core is endorsed but not bundled. Easy, tested, works already for netstandard1.6. we delay decision a bit, so more time to do it right
    • cons: is not bundled, no legal issues afaik (like others oss package used by MS). so offline scenario need care (populate at first use, or tell ppl to download in an local feed who is 2 minutes of work). but is a tradeoff who doesnt make haste on important decision.

My added scenarios.:

  1. OSS users (developer) experience, must be simple. better to be hard for maintainer:

    • having multiple packages is annoying for users. is already hard understand netstandard vs net40 vs pcl. at least solution now is simple for them: add FSharp.Core package.
    • versions to use, more work: FSharp.Core version may diverge from FSharp.Core.netstandard

  2. use already existing packages

    • netcoreapp can import library in the netstandard2.0 closure. This help devs. But if that package reference FSharp.Core pkg, now has two fsharp.core.dll => fail

  3. can be merged later:

    • i am worried. if template use FSharp.Core.netstandard and is packaged as nuget, from now on that package depends for a lot of time on that (now just a little timeframe, because netstandard2.0 is good). is hard to merge a metapackage later.
cartermp commented 7 years ago

@matthid

And I'm not even sure people can tell the difference if F# is in the box or not as long as the entry points work (dotnet new -lang f#). Or do they?

This is orthogonal to the packaging of FSharp.Core in the long-term, but to address this point:

There were two occasions in the past year where F# was broken on .NET Core because it was an out-of-band component. The first was far more severe, but both resulted in people trying out .NET Core with F# only to find it broken. Being in-band with the SDK makes it known and obvious to those working on the SDK if and when F# gets broken by their changes.

cartermp commented 7 years ago

To address the point about other Microsoft teams taking on a third-party library:

It's probably not what you think. There is a serious investment made in ensuring that those components are serviced by Microsoft because they are distributed via other Microsoft bits. In other words, because ASP.NET uses JSON.NET, they own all servicing for the version of JSON.NET that they have included in their distribution. They are not allowed to just punt those concerns to the package author.

forki commented 7 years ago

Philip we know these legal issues. Really. I'm dealing with this stuff for many many years. Please don't start to go this way on us.

We know that Microsoft has (valid) legal concerns, but that needs to fit with rest of community or we will eventually fork or rage quit. Please work with the community on such things. The rfc is a good start. Being open and discussing all the issues is the way forward. Even if some people give negative feedback here, that's only to make it work for everyone. We are your userbase. We actually care enough to not have rage quitted.

enricosada commented 7 years ago

There were two occasions in the past year where F# was broken on .NET Core because it was an out-of-band component. The first was far more severe, but both resulted in people trying out .NET Core with F# only to find it broken. Being in-band with the SDK makes it known and obvious to those working on the SDK if and when F# gets broken by their changes

@cartermp this is not how things where. It was broken because the fsc was not ready yet for that version. like fsc is not ready now for netcoreapp2.0.

We know exactly when things doesnt work. dotnet/cli has F# in the test suite EACH commit restore/build/run the templates. I know that, but was not possibile to fix before rtm. That's why now template use 1.0.* and 4.1.* versions, so for example i can fix sdk 2.0-preview1 NOW if you give me the fsc. New F# sdk design cannot do that, but is a tradeoff you choosen, so is ok, your risk. I can add a message "not ready yet, see github issue or wiki" (btw is a good idea for sdk2.0 now :D) easy. but that's it.

First time was not possibile to fix that anyway. is ok. Second time was not possible to update because while i tried using myget feed the update (same issue about fsc), i cannot release that package on nuget.org, because nuget.org support semver1.0 and myget2.0, and a .net team member choose 1.0.0-preview2.1-0001 who is not a valid semver1.0 (so cannot go on nuget.org). really hard to spot, if you dont push it on nuget.org

Do you as @cartermp as VF# PM can really say now that "in-band" mean that MS will stop the .NET Core Sdk 2.0 RTM release because fsc netcoreapp2.0 is not ready? or FSharp.Core netstandard2.0 is not ready? Just dont say "will be ready" please.

matthid commented 7 years ago

@cartermp My point was more like I don't understand why it's so urgent now. I get the reasoning on why we want to do it. And I'm not even against F# OOTB support for netcore in general (I get that it might help from an engineering and testing perspective).

Note that it's not related to this issue, but in general, there is also a technical reason to keep it outside of the distribution: It ensures that the platform is extendable from the outside. For example, fable is still trying to get into this new world as well...

forki commented 7 years ago

Matthias, fable will probably retract from netcore if Microsoft closes things. But currently we are optimistic.

ReedCopsey commented 7 years ago

@forki mentioned:

But currently basically all F# projects I know use the FSharp.Core package. Tbh I don't remember a single project in OSS or commercial that really uses the shipped fsproj template with Reference Assemblies fsharp.core. It's just wrong. Let's pleases focus on ecosystem experiences. VS being one part of this.

I'd second this - Avoiding the Reference Assemblies version of FSharp.Core, and adding the NuGet package (and appropriate binding redirects) is probably the solution to the single biggest hurdle to new users coming to F#.

When doing any real F# project, which uses libraries, and especially when trying to integrate F# into existing mixed language solutions (with C#/C++/etc), the NuGet package is pretty much the only way to make things work cleanly.

At this point, having F# out of Reference Assemblies (and the GAC, which has already happened) would dramatically simplify things for people coming to F# - grabbing the wrong version from Reference Assemblies (or previously the GAC) is a huge problem, and has been for a long time.

cartermp commented 7 years ago

Correct me if I'm wrong, one of your (OSS community's) core concerns there seems to be a mistrust in our (Microsoft's) delivery for F# on .NET Core 2.0 and .NET Standard 2.0. Our stated urgency doesn't appear to be important from your perspective. @KevinRansom has described multiple times why the existing SDK extension and packaging was not sufficient from our point of view, given our urgency and the general approach taken. @enricosada disagreed with those points, because his approach did work for the scenarios he laid out. This is compounded by very bad communication from us on this front.

Honestly, I'm struggling to see how we can move forward from this. I really want to. But our reasoning behind anything does not appear to be satisfactory to you on any front. I do not believe that we are capable of discussing the issue at hand (FSharp.Core packaging) because it's preceded by fundamental disagreements about F# on .NET Core to begin with. What is the best medium for that discussion?

KevinRansom commented 7 years ago

@enricosada Well I use it fine ... and I haven't updated the build to dotnet 2.0 yet. You just need to deploy a deps.json and fscruntime.json that targets 2.0.

I created them by making a new project targeting netcoreapp2.0 called fcs and using the current Microsoft.FSharp.Compiler.nuget And Microsoft.FSharp.Core.nuget as dependencies and publishing it. then grabbing the generated .json files. I thought it was sneaky but kind of a neat trick ... After all none of the apis we depend on have been taken away. It was just a matter of convincing the loader to load it.

You should be able to do the same ... let me know if you need help.

Kevin

matthid commented 7 years ago

I think it is possible that you surprise everyone with a working solution, just don't break Paket, FAKE and similar style projects ;). It would be really nice if you would not break paket+netcore style projects as well. Or at least give us a window to react and open issues there.

Most OSS-Maintainers (including myself) just fear that we have to apply a bunch of bandages everywhere and add even more workaround so stuff works. Just consider that we often do this in our free time and don't like fixing stuff we didn't break.

Doing paket update and then needing to fix broken stuff everywhere is not something I like doing, especially considering this will be reverted at some point and then I have to do everything again?

With that in mind: Please surprise us, I'm pretty sure you can ;)

enricosada commented 7 years ago

because it's preceded by fundamental disagreements about F# on .NET Core to begin with

Really @cartermp is not like that. I disagree on tradeoff about fsc bundled, i was ok with target file inside (just worried about lose the ability to not be able to update for bugs, but ok). But this is another area. I am not disagreeing because you obsoleted FSharp.NET.Sdk. One thing is be disappointed about communication (and we resolved that soon afaik), the other is the technical discussions who i like to discuss because well, i like that part.

Sorry if seemed from my comment i didnt trust your delivery (my english is bad), is not that. i was speaking about the "in-band" meaning.

I am not worried about not having an fsc/fsharp.core.dll ready in time either. I was just objecting about what "in-band" mean pratically, because you said "because it was an out-of-band component". That was not the reason at the time ihmo. Different time. was really hard to create a fsc, because was first version. lot of wip. Lot of stuff changed in better thx to Kevin (the fsc package, the tests, fsharp.core.netcore package, portable pdb who are now used in vscode debugger etc).

I didnt lose trust in vf# team (you or @KevinRansom) delivery about this, and i always said to anyone anyway i WAS OK with it, and it is. So let's discuss in private this, if need. But "in-band" is a general term for me who hide lot of choices, that's it. fsharp.core is one of these.

But can we at least discuss the technical choices? this one about FSharp.Core impact a lot the community, like templates. it's like that. Because can create friction for users, so i just adding this feedback and trying to find a way for everyone.

KevinRansom commented 7 years ago

@enricosada the work you've been doing has been fantastic. As I have said before an opportunity arose to ship with the DotnetCli, this was not an opportunity to be missed. Integrating directly into the SDK meant that the msbuild targets glue that was the FSharp.SDK just got merged directly into the dotnet sdk, meaning that those guys forever get to maintain the glue and forever own it's compatibility. It also means that no one has to add a reference to the compiler in their project. Certainly no C# or VB developer would expect to do it? those guys come in the box right?

There was never any intent to be mean or difficult about it, it's just that things change and when they do they somethimes change quickly after all we went from project.json everywhere to projfiles everywhere requiring vast rewrites, including for you and the SDK. I think of this pretty much as merging the FSharp.Sdk.

I would love to have a discussion about FSharp Core.nuget packages. I hope this helps

Kevin

PS check the response about how to run the compiler on dotnet core 2.0 it's really cool, and I'm betting you can update fsharp.core.nuget pretty quickly and get the sdk running again.

forki commented 7 years ago

Philip, yes there is a lot of mistrust in Microsoft and meeting its own deadlines. I mean Microsoft gave us so many reasons for this over the years. I spent sooo much time fixing other people's nuget settings over the years (even before I started paket). Mostly fsharp.core or Newtonsoft related. And Microsoft did absolutely nothing to solve root causes. Nothing. In all the years.

Anyways here I see hope. This is an RFC and allows communication. The main goal should be to keep fsharp.core the goto package. VS needs to adapt and finally give up referencing Reference Assembly or GAC libs. Dotnet core can be shipped in subpackage if really needed (don't really see why since size is a no issue. Dotnetcore downloads whole Internet anyways). Mono support is nearly ready since Don merged the repos. So basically it's only transfer of ownership and putting proper build script (with signing) into VF# repo. Things that we discussed over and over again. We actually pushed for this for so long but somehow now it's an emergency because MS internal deadlines come into play

forki commented 7 years ago

"It also means that no one has to add a reference to the compiler in their project. Certainly no C# or VB developer would expect to do it? those guys come in the box right?"

According to the related issue count on paket this scenario is quite common in C# land. Many users reference the C# compiler via nuget in order to get newer versions of the compiler and also to ensure that CI servers use the correct compiler version. This is a sane approach.

haf commented 7 years ago

add a reference to the compiler

As many references locked down and specific in paket.lock as possible, please. I've spent weeks just fighting different MSFT installers when I was on Windows without paket, on different CI-servers.

nosami commented 7 years ago

A couple of points.

VS for Mac currently uses the NuGet version of FSharp.Core. Due to the viral nature of strongly named assemblies and also us adopting the official Roslyn packages (and some IVT use), we later started to strongly name the packaged version of FSharp.Core at build time using https://github.com/dsplaisted/strongnamer

Package size isn't an issue for Xamarin. We bundle FSharp.Core with Visual Studio for Mac and it is available for offline use (along with a bunch of other commonly used packages). We add a local package feed that ships with the IDE.

For years, FSharp.Core has been built internally for various frameworks for GAC usage. We'd like to get out of that business.

forki commented 7 years ago

@jason :hugs:

dsyme commented 7 years ago

A couple of reminders

  1. Before contributing to this thread please make sure you have read the RFC document fully

  2. Please stay on-topic for the RFC discussion.

Thanks! Don

dsyme commented 7 years ago

In the name of technical accuracy and avoiding confusion I made about 5 edits to comments above to clarify the terminology about "getting FSharp.Core from the GAC". I replaced these references with "getting FSharp.Core from Reference Assemblies (or, previously, the GAC)", since I'm certain that the comments were about referencing machine-wide installations of the package (Reference Assemblies), not the GAC specifically.

See also https://github.com/fsharp/fsharp.github.io/blob/master/_posts/2015-04-18-fsharp-core-notes.md#do-not-assume-fsharpcore-is-in-the-gac

forki commented 7 years ago

@dsyme yes thanks for the clarification. Yes there is a difference between reference assemblies folder and GAC. Relying on GAC instead of copy local was even more confusing.

forki commented 7 years ago

Also I think many of the original issue will go away since @dsyme merged optdata and sigdata. That's really good progress.

forki commented 7 years ago

One comment about reference assemblies: I think it was a good idea. But we should have made it a "default packages" folder. Installer could have copied all needed packages over there and we could just use local nuget feed features in paket/NuGet. Then offline scenarios and upgrade would be much easier (at least in my mind).

enricosada commented 7 years ago

added https://github.com/fsharp/fslang-design/pull/201 to remove the file size issue from discuss. I added stats:

offline cache compressed nupkgs for offline scenario % Note
my local VS local feed 2500MB 100,00 by VS install, not me
Fsharp.Core nupkg 7MB 0,28 added there by me
nuget cache uncompressed nupkgs %
my local nuget cache - 1074 distinct by id, * versions 40000MB 100,00
Fsharp.Core - 13 versions from 2.0 370MB 0,93

NOTE: sending this comment on github as http request (909 bytes => ~1KB)

dsyme commented 7 years ago

Thanks @enricosada, I replied on the PR thread.

dsyme commented 7 years ago

I have added a draft of a second proposal to the RFC, please see https://github.com/fsharp/fslang-design/pull/203 or "Proposal B" in the RFC document. It's just a draft so far.

dsyme commented 7 years ago

@haf @matthid @enricosada @cartermp @7sharp9 @nosami Your feedback on proposal B would be much appreciated, thanks