Create Binary Release with Jupyter Support

[Rickasaurus]

Seeing as how we have Jupyer support now (#51) it seems like we're due for a binary release. Is there anything standing in the way of this?

[dsyme]

👍

[Rickasaurus]

I talked to @prosconi and he says it should be as easy as running InnoSetup to generate an executable. I'd still like to make sure there's no major outstanding issues though.

[cgravill]

A binary release would be great to do. There are some outstanding issues from changes to the environment.

Jupyter 4.1 starts to bring in some protocol changes which seem to create issues with restarting #55 and spurious warnings. Also, more people are likely to have VS2015 only and therefore experience MSBuild issues on #53 and the problems around compulsory references #52, particularly on Linux.

It would be good to address these before a binary release. It's also why I've held off on switching this branch into master.

• For restarting, @FilippoPolo has investigated further and traced part of it back into Jupyter. I think this is ongoing
• On compulsory references, I think we should stop including them, @npmurphy has a solution for the F# Charting utility functions in IfSharp, something like you suggested on Compulsory reference to (old version of) FSharp.Charting blocks reference of newer versions #52 I understand
• For MSBuild, we could just insist people use VS2015 but that's unhepful. I'll see if it's possible to include MSBuild somehow

[Rickasaurus]

Thanks @cgravill. Do you think moving to nuget for the F# core and stuff in order to standardize on a version would be the way to go?

[FilippoPolo]

For reference, the issue @cgravill is talking about is jupyter/notebook#1281.

[cgravill]

Filippo has fixed the protocol behaviour #64
I've sorted out the MSBuild issue by changes to F# complier services.
We're still working on the #65 for the dependencies.

As a test I've created a zip based binary release: https://github.com/fsprojects/IfSharp/releases which works cross-platform. Creating more friendly and automated installers seems like a good idea too, especially as we finish up.

[cgravill]

Just to note that the various issues have now been resolved. We've been providing some alpha pre-releases binaries as zips and fixed up any issues.

We're now clear to try building automated installers as well.

[cgravill]

I made some updates to the Windows installer so it picks all the required files. One issue is that we current install to Program Files. That with the functionality to fetch dependencies with Paket from NuGet currently tries to write to the local directory. Writing to Program Files is disallowed by default.

We could configure the embedded Paket to look and write in an AppData folder but that would require configuring other scripts to look in there too. I wondered if it might be better to install everything to local AppData (like how e.g. Chrome does). It would make F# Jupyter be user specific and is a possible answer how to support F# versions side-by-side e.g. 4.0 and 4.1.

Thoughts?

[sylvanc]

I think an appdata/local installation is a good idea, even if we change where Paket puts packages.

[sylvanc]

Closing, as the jupyter branch has been merged to master.