Swtiching to Powershell as the default for helper scripts

Coordinator
Jul 17, 2014 at 11:28 PM
Just fishing for comments and feedback here, this is not a committed plan in any way. I am curious what others think, whether this would be seen as a positive change or not.

There are currently a handful of batch scripts in this repo that are needed when doing complete builds or starting tests: update.cmd, RunTests.cmd, BuildTestTools.cmd.

I am personally not fond of batch scripting, and would prefer to change these scripts to Powershell, and to use Powershell as the default script language for similar helpers in the future. Despite its quirks, Powershell is far more powerful, easier to use/debug, has better tooling, has rich .NET-based extensibility, and is generally better supported by Microsoft at this point than batch. It's been the flagship shell for Windows for almost 8 years now - hardly a newfangled thing nobody is familiar with.

Switching to powershell also opens the door to a better repo enlistment experience. I've heard feedback recently that it is quite painful to set up a Visual F# enlistment (need to download and install lots of SDKs/tools, lots of steps required to build and run tests, etc). Automating these kinds of things (with error handling and command-line options) becomes much simpler in Powershell.

I'm not talking about the test cases, btw, many of which also heavily rely on batch. The tests will hopefully all be migrated to a compiled nunit/xunit/mstest kind of system in the not too distant future...

What do people think? Powershell has been my default shell for years, so it seems like a big win to me. But I know many are still batch-attached.
Jul 18, 2014 at 1:49 AM
Since the Visual F# Tools are Windows-only, I don't see a problem with this.
Jul 18, 2014 at 6:00 AM
Noooooooooo! Please don't.

Why do you want to make it even harder to merge things between this and open source repo?
Powershell is Windows-only and therefore a big no go for open source. Since all the development of things like FSharp.Core.dll will be here we should not rely on Windows (at least we should not go deeper into Windows-only)

Don't get me wrong I really want to see the build script happening, but just not this way. It will not bring us further since will have this security problems on every local machine and build server. It will be a nightmare.

I still can't understand why you don't go the same route as FCS or F# open source repo on github. That would improve compatibility. Public CI and automatic build for pull requests has to be the goal. It's hard but not impossible.
"it's the flagging shell on Windows for almost 8 years now"
Remember Microsoft developed a really scripting language that works on all platforms. ;-)
Coordinator
Jul 18, 2014 at 6:12 AM
Edited Jul 18, 2014 at 6:12 AM
I'm not sure I understand - batch scripting is Windows-only as well, no? Powershell and the batch engine are equally closed-source. Is there some batch emulator used by Mac/Linux?

And what security problem are you referring to - Powershell incorporates deliberate design decisions aimed at closing the security gaps left by batch and vbscript.
Jul 18, 2014 at 6:18 AM
I mean you have to set-executionpolicy and you need an administrator for this. This will bring big pain.

And I don't think we should use batch or shell. Did you look into the FCS build process?
Coordinator
Jul 18, 2014 at 6:54 AM
There is no requirement whatsoever to do anything with admin privs that does not already require admin privs (e.g. adding fsharp.core to GAC after build). Setting the ExecutionPolicy for the current user doesn't require admin permissions, and can even be done in the setup script itself.

The question of overhauling the build infra so that no scripts at all are used is not related to this, that's a separate discussion.

For now, the fact is that we have a few helper scripts. I've heard requests for those to be improved, or to add at least a couple more. What is the rationale for sticking with a weak, arcane, legacy-from the-80s scripting solution, when a modern, rich, popular, supported, functional-style, .NET-based one exists?
Jul 18, 2014 at 7:09 AM
From my Twitter stream in the last couple of minutes I can tell that it's not popular in the F# open source community. ;-)
Jul 18, 2014 at 7:23 AM
  • Maybe Visual F# Tools are Windows-only but other F# projects and F# itself is not, it's much better have same thing for scripting.
  • Powershell is ugly. It's "Power's Hell" and I don't want to have the hell there, Perl is the beautifulest language when ps is near (personal opinion).
  • We already have FAKE there and it could handle most of things.
  • My current Windows 7 setup even can't perform ps scripts by clicking on them, I don't know where is trouble But I don't even want to know.
Jul 18, 2014 at 7:38 AM
I REALLY think we should use the F# tools that were created to do this work, e.g. FAKE and fsx scripts.

If you take a look at FSharp.Compiler.Service you can see it works really well there, and thats a branch of the F# compiler so you cant get a better example than that.
Jul 18, 2014 at 7:41 AM
Incidentally the test scripts were partially converted to nunit format for mobile testing on Android and iOS, look at the github oss F# compiler
Jul 18, 2014 at 7:59 AM
Edited Jul 18, 2014 at 8:04 AM
Making powershell central to any F# core tool is a terrible idea. This biggest reason is that there's no full mono implementation of powershell. Also, if you're using F#, you're going to have the F# dependencies around, so you may as well use F#. It's a better scripting language than powershell in any case. Finally, I'd hate for us to be further tainted by being too microsoft-centric, which is exactly the message that using powershell sends to people outside of the ecosystem,

Why not just use FAKE? It's good enough for most of the other F# projects, and recently many C# ones too. Better to have a standard tool chain across projects (unless there's an extremely compelling reason) so that they're all accessible to new contributors.
Jul 18, 2014 at 10:02 AM
I think that having F# dealing with F# issues on its own is an excellent idea given that the language is far more complete than anything powershell can offer, regardless of whether it is ever going to have a mono implementation or not. As somebody who is enjoying using F# in different platforms, I prefer tools that guarantee me that portability; FAKE is one of them and using F# on its own rather than binding it to powershell is going to make it even more enticing an option for FOSS people. so I am against any powershell integration, if any of this matters.
Jul 18, 2014 at 10:46 AM
Please don't use powershell. Totally with @7sharp9
Jul 18, 2014 at 1:13 PM
Yes, I like this idea. In fact, I even converted some of the batch files already for my own local development purposes -- I'm happy to contribute the progress I've made so far if you want.

FAKE seems like an OK idea too, especially since it provides portability across different OSes.

I'm also really looking forward to having the rest of the tests migrated away from a batch + Perl system to a compiled, F# + NUnit/XUnit-based system.
Jul 18, 2014 at 3:22 PM
I'm for FAKE, too.
Jul 18, 2014 at 3:57 PM
Please do not use PowerShell. Use FAKE. F# has powerful scripting ability. Adding another technology is unneccesary.

PowerShell is largely Windows centric and therefore not cross platform with BSD/Linux. I really want cross platform to be a strong consideration in all F# decisions.
Coordinator
Jul 18, 2014 at 5:27 PM
Thanks everyone for the feedback. Nothing quite like the fresh sting of overwhelming disagreement with one's idea ;-)

I probably should have framed this differently. The primary goal is really to move away from batch, our current, worst-of-all-worlds solution. I'm flexible on what we move toward, and tossed out Powershell as one (IMO very attractive, at least on Windows) alternative.

From above it's clear that fsx/FAKE are strongly preferred, for a variety of reasons. That's awesome, and I'm happy to get behind it. As long as we move away from batch scripting!

There is already another thread going, directly addressing FAKE as build driver. Let's use that for further discussion on this specific topic.
Coordinator
Jul 18, 2014 at 7:21 PM
Let's use this thread for improving our testing and scripting infrastructure. Since I like the notion that we do something to improve it, and Lincoln has a much better view on what will work and be compatible with MSFT internal processes than I do, and how to align that with the community needs.

I will direct the other thread here.

Kevin
Jul 18, 2014 at 8:43 PM
NOOOOO! Please don't do that. These are two, entirely different topics. This topic is about this project's build scripts. The other is about re-imagining the F# project system.
Jul 21, 2014 at 12:03 AM
Well, I think PowerShell would've been a fine idea to replace the batch scripts -- it's at least an improvement to get the project going in the right direction as far as cleaning up the scripts, and it could have easily been converted to F# scripts later.

I propose we convert the batch files to *.fsx files, so I've sent a pull request with a couple of the files converted already. I didn't use FAKE, they're just simple F# scripts.
Coordinator
Jul 21, 2014 at 2:20 AM
I would really like to see the Fake equivalent of this script to be able to compare the two approaches. However I would take a lot of convincing that this is better than the original batch file. It is also true that I am old and set in my ways.
Jul 21, 2014 at 7:50 AM
Using powershell would be a terrible idea as many people say; beginning with portability which is a very important concern for fsharp programmers like myself who enjoy the language in non-microsoft platforms. It is very nice to know that you don't need to do a separate project for maintaining the same codebase in another platform. Using powershell would make my life way more difficult.

FAKE is probably the best tool all around for this if you ask me.
Jul 21, 2014 at 3:45 PM
Powershell only requires admin to run scripts in version 1.0. Versions past that can override the scripting restriction on a per user basis which doesn't require admin
Jul 22, 2014 at 6:28 PM
Coordinator
Jul 22, 2014 at 8:10 PM
Okay so we now have two alternate proposals for replacing some scripts :
We have a raw .FSX scripts : https://visualfsharp.codeplex.com/SourceControl/network/forks/jackpappas/fsharpcontrib/contribution/7155#!/tab/changes
And we have a fake script here: https://visualfsharp.codeplex.com/SourceControl/network/forks/forki/fsharp/contribution/7167#!/tab/changes

They both seem like absurdly large changes to replace a few meagre batch files, and so I assume they are considered part of an overall goal to produce a systematic approach to the build and execution of the test cases in this repo. As part of such a plan I think these could be considered a start ... do I understand the intent correctly? And how do we ensure that we continue to make good progress to that end? ... who do we hold accountable for driving this work?

Thanks

Kevin
Coordinator
Jul 22, 2014 at 8:29 PM
Tomas Petricek pointed out on twitter: https://twitter.com/tomaspetricek/status/491679647386845185 that some existing open source projects already use Fake for their build and test infrastructure. So incorporating other projects and using similar technologies improves the effectiveness of the community. Allows them to not have to learn the foibles of every projects different way of doing things.
Jul 23, 2014 at 7:03 AM
Hi Kevin,

actually both proposals already do more than the original cmd files. Don't forget we also build Protocompiler and Fsharp.core and so on.
I removed unused nuget config files from my proposal to show that the actual code is NOT absurdly large :-)
I admit that commiting nuget.exe is a large change, but it will allow us to download NUnit and other tools later.

Yes they are a only start for a "one-click-build" script, but IMHO they are a good start. I'll update the DEVGUIDE in my pull request to reflect the changes.
If I find the time I will also create a NUnit test target.
who do we hold accountable for driving this work?
I don't think that's a valid question in OSS land, but I don't want to start a discussion here.

how do we ensure that we continue to make good progress to that end?
Just comment on the Pull Request(s) - You might want look at https://github.com/octokit/octokit.net/pull/142 where we discussed the process of building a build script with the guys of github.
Cheers,
Steffen
Jul 23, 2014 at 8:31 AM
I added a target for the core unit tests see https://visualfsharp.codeplex.com/SourceControl/network/forks/forki/fsharp/changeset/ce68a087606fc110f69d2a05ab2cccf49d97f944

It automatically downloads (a blessed version of) NUnit see https://visualfsharp.codeplex.com/SourceControl/network/forks/forki/fsharp/changeset/a5e98d8f7908b3ae13d283730d26b633957b4efc - so we don't need to install NUnit anymore (at least not for this part)
Coordinator
Jul 23, 2014 at 7:47 PM
I realize this may seem like a no brainer to you, but I'm going to have to think about ... probably quite a lot. I am partially inclined, I can see the potential for a lot of benefit but I am not quite convinced. I think that is my problem rather than yours, I am going to have to let this digest for a bit and play around with fake for a while.
Jul 23, 2014 at 8:16 PM
The advantage might be smallet for someone who knows all the tools and uses them every day. But we're talking about open source here. There are people out there who just want to play a bit with the project and maybe find a bug or want to contribute a list helper function.
They don't want to learn all the really complicated things that are going on in this project.
Coordinator
Jul 23, 2014 at 8:34 PM
I get it, like I said I need to think about it a bit.
Jul 25, 2014 at 1:18 PM
forki wrote:
The advantage might be smallet for someone who knows all the tools and uses them every day. But we're talking about open source here. There are people out there who just want to play a bit with the project and maybe find a bug or want to contribute a list helper function.
They don't want to learn all the really complicated things that are going on in this project.
While I support your other arguments, this is one severly wrong in my opinion. A current example for the difficulties that can pop up if the tools are used without a proper understanding of the underpinnings is here: https://github.com/tpetricek/FSharp.Formatting/issues/167. This probably resonates with Kevin´s gut feelings.
Jul 25, 2014 at 2:22 PM
Oh there will definitely be problems along the way. That's for sure.
Coordinator
Jul 29, 2014 at 9:33 PM
An update:

We have not yet come to a conclusion about this, my inclination is to give a try and see what issues arise. But we are currently super busy on the release of the oob and some internal work.
Aug 17, 2014 at 1:26 PM
I've been thinking about this a bit, and I've come up with another possible solution. The batch scripts that we're talking about here are neither large nor complicated; they only serve to call msbuild and a few external tools like gacutil and sgen. Why don't we just replace them with MSBuild projects (*.proj)?

For those of you who just read "MSBuild" and had the knee-jerk reaction "noooooooo, not MSBuild!!" -- these should be very simple scripts, not much more than a simple list of things to be processed during a build of the source tree. The upside to this is that it will get rid of the batch files (taking a step towards getting the test suite running on non-Windows platforms) without introducing additional dependencies (PowerShell or FAKE).

IMO, this is the best solution because it's the simplest and easiest -- and it will allow us to move past this and onto the real work that needs to be done to clean up the test suite, which is to write an NUnit-based test runner to replace the mix of batch, Perl, and F# scripts currently used by the test suite. See this discussion for details: https://visualfsharp.codeplex.com/discussions/541792
Aug 20, 2014 at 3:51 PM
Edited Aug 20, 2014 at 3:52 PM
Responding to Lincoln's comments in the last PGI, Lincoln mentioned that all Windows developers should by now know Powershell. I know very few who know or even use Powershell regularly. I don't. I use it for running poshgit and that's all.

I agree with the general sentiment on this thread and in the chat from the recording. Use whatever tools you want so long as they work. If you choose Powershell, understand that any synchronization with the OSS fsharp/fsharp will be limited due to the fact that Powershell is Windows only. Also, you are likely going to reduce the number of willing contributors, so don't wonder why people don't contribute to this part of the project.

In general, while I would really like to see this project leverage FAKE, I prefer @jackpappas' recommendation of using .proj files to either the current state or Powershell. They suck for everyone but are at least cross-platform.
Coordinator
Aug 20, 2014 at 5:08 PM
Sorry for not updating this thread earlier, I have been meaning to, but I keep getting sidetracked. We are working on accepting Forki's FAKE pull request. It has turning in to quite a large job though. I can't make any promises but I expect before the end of next week we will have something to check in.

Kevin