_____101 |> F# Coding Ecosystem: Paket && Atom w/ Paket

One extremely useful tool to use with F# is Paket. Paket is a package manager that provides a super clean way to manage your dependencies. Paket can handle everything from Nuget dependencies to git or file dependencies. It really opens up your project capabilities to easily pull in and handle dependencies, whereever they are located.

I cloned the Paket Project first, since I would like to have the very latest and help out if anything came up. For more information on Paket check out the about page.

git clone git@github.com:fsprojects/Paket.git

I built that project with the respective ./build.sh script and all went well.


NOTE – Get That Command Line Action

One thing I didn’t notice immediately in the docs (I’m putting in a PR right after this blog entry) was anyway to actually get Paket setup for the command line. On bash, Windows, or whatever, it seemed a pretty fundamental missing piece so I’m going to doc that right here but also submit a PR based on the issue I added here). It could be I just missed it, but either way, here’s the next step that will get you setup the rest of the way.


Yeah, that’s all it was. Kind of silly eh? Maybe that’s why it isn’t documented that I could see? After the installation script is run, just execute paket and you’ll get the list of the various commands, as shown below.

$ paket
Paket version
Command was:
available commands:

	add: Adds a new package to your paket.dependencies file.
	config: Allows to store global configuration values like NuGet credentials.
	convert-from-nuget: Converts from using NuGet to Paket.
	find-refs: Finds all project files that have the given NuGet packages installed.
	init: Creates an empty paket.dependencies file in the working directory.
	auto-restore: Enables or disables automatic Package Restore in Visual Studio during the build process.
	install: Download the dependencies specified by the paket.dependencies or paket.lock file into the `packages/` directory and update projects.
	outdated: Lists all dependencies that have newer versions available.
	remove: Removes a package from your paket.dependencies file and all paket.references files.
	restore: Download the dependencies specified by the paket.lock file into the `packages/` directory.
	simplify: Simplifies your paket.dependencies file by removing transitive dependencies.
	update: Update one or all dependencies to their latest version and update projects.
	find-packages: EXPERIMENTAL: Allows to search for packages.
	find-package-versions: EXPERIMENTAL: Allows to search for package versions.
	show-installed-packages: EXPERIMENTAL: Shows all installed top-level packages.
	pack: Packs all paket.template files within this repository
	push: Pushes all `.nupkg` files from the given directory.

	--help [-h|/h|/help|/?]: display this list of options.

Paket Elsewhere && Atom

If you’re interested in Paket with Visual Studio I’ll let you dig into that on your own. Some resources are Paket Visual Studio on Github and Paket for Visual Studio. What I was curious though was Paket integration with either Atom or Visual Studio Code.

Krzysztof Cieślak (@k_cieslak) and Stephen Forkmann (@sforkmann) maintain the Paket.Atom Project and Krzysztof Cieślak also handles the atom-fsharp project for Atom. Watch this gif for some of the awesome goodies that Atom gets with the Paket.Atom Plugin.

Click for fullsize image of the gif.

Click for fullsize image of the gif.

Getting Started and Adding Dependencies

I’m hacking along and want to add some libraries, how do I do that with Paket? Let’s take a look. This is actually super easy, and doesn’t make the project dependentant on peripheral tooling like Visual Studio when using Paket.

The first thing to do, is inside the directory or project where I need the dependency I’ll intialize the it for paket.

paket init

The next step is to add the dependency or dependencies that I’ll need. I’ll add a Nuget package that I’ll need shortly. The first package I want to grab for this project is FsUnit, a testing framework project managed and maintained by Dan Mohl @dmohl and Sergey Tihon @sergey_tihon.

paket add nuget FsUnit

When executing this dependency addition the results displayed show what other dependencies were installed and which versions were pegged for this particular dependency.

✔ ~/Codez/sharpPaketsExample
15:33 $ paket add nuget FsUnit
Paket version
Adding FsUnit to /Users/halla/Codez/sharpPaketsExample/paket.dependencies
Resolving packages:
 - FsUnit 1.3.1
 - NUnit 2.6.4
Locked version resolution written to /Users/halla/Codez/sharpPaketsExample/paket.lock
Dependencies files saved to /Users/halla/Codez/sharpPaketsExample/paket.dependencies
Downloading FsUnit 1.3.1 to /Users/halla/.local/share/NuGet/Cache/FsUnit.1.3.1.nupkg
NUnit 2.6.4 unzipped to /Users/halla/Codez/sharpPaketsExample/packages/NUnit
FsUnit 1.3.1 unzipped to /Users/halla/Codez/sharpPaketsExample/packages/FsUnit
3 seconds - ready.

I took a look in the packet.dependencies and packet.lock file to see what were added for me with the paket add nuget command. The packet.dependencies file looked like this now.

source https://nuget.org/api/v2

nuget FsUnit

The packet.lock file looked like this.

  remote: https://nuget.org/api/v2
    FsUnit (1.3.1)
      NUnit (2.6.4)
    NUnit (2.6.4)

There are a few more dependencies that I want, so I went to work adding those. First of this batch that I added was FAKE (more on this in a subsequent blog entry), which is a build tool based off of RAKE.

paket add nuget FAKE

Next up was FsCheck.

paket add nuget FsCheck

The paket.dependencies file now had the following content.

source https://nuget.org/api/v2

nuget FAKE
nuget FsCheck
nuget FsUnit

The paket.lock file had the following items added.

  remote: https://nuget.org/api/v2
    FAKE (4.1.4)
    FsCheck (2.0.7)
      FSharp.Core (>=
    FSharp.Core (
    FsUnit (1.3.1)
      NUnit (2.6.4)
    NUnit (2.6.4)

Well, that got me started. The code repository at this state is located on this branch here of the sharpSystemExamples repository. So on to some coding and the next topic. Keep reading, subsribe, or hit me up on twitter @adron.


Why F#, and Why Not Windows

I posted my previous entry and got a few retweets and favorites. One reply came back and made me think, “ah, it might not be obvious why I’d like to have F# on something besides Windows.” Well, here’s a list of why I want to use F# on non-Windows platforms.

  1. F# is a good language. I can’t say the best, since I honestly don’t have enough experience with it or other functional languages to really declare a victory in my opinion. However I’ll be doing some work with Scala, Haskell, and Erlang in the next couple of weeks for testing and use with some upcoming projects.
  2. There are only two technology stacks that will let one spin up an actual application on all of these technologies: OS-X Cocoa, Windows, Linux, Android, and iOS. These two tech stacks are .NET and than the Node.js JavaScript stack – with the latter being purely web based. (Yes, some could argue Adobe’s tools or the Java stack, but I’m not going down that route right now, as both are somewhat bloated and convoluted in ways we can go into at some other time)
  3. With F# I get a clean functional language that I can build native mobile, tablet, or OS apps and all the web services that I want with two advantages over Node.js. The first is the performance edge and can likely be tuned more anyway. Being paired with SignalR one can even get some wicked simple and fast real-time capabilities with minimal code. The second is it takes less F# code to do similar JavaScript things and compute, let me tell you about compute with F#. F# can run things that JavaScript just really can’t measure up to when it comes to compute. But aside from these things, they’re both excellent tools and I wanted to have F# in my tool belt.
  4. There’s always the backup plan of just converting to JavaScript too, if I needed that sort of thing. Check out FunScript.
  5. The community around F# is actually pretty cool, there are good, solid, intelligent, and friendly people in that community. Having a good community of people always makes getting into a new language or related tech much better then when the community consists of asshats or jack ass savants.

Other great things that add to the usefulness of F# include WebSharper.NET MVC 5 and Web API, Nancy API, Suave.io, and there are others.

So those are the reasons I decided to move forward with F#: solid language, provides a solid technical stack with options, it’s functional and clean with extra compute power, and a kick ass community. Of course F# came from the land of Windows and Softies (that’s short for Microsofties, and I didn’t make that up). But F# was handed over to the open source community and currently moves forward autonomously of Microsoft. By proxy of this event, and other culminating events of late, F# can easily run on operating systems besides Windows. I’m not a fan of Windows, and here’s a few snarky (yet very real) reasons why I don’t even want to mess with Windows (except in the situation where I really do want to or need to use Visual Studio).

  1. Windows is still slow. I could go into the reasons, but it tends to build slow, behave slow, be prone to the attention of spammers and such, only in the last X years has it managed security in a half ass decent way, which also leads to slowness, and … oh you get the idea. It’s a slow OS.
  2. It’s flippin’ humongous. Now is this really a problem? Not really, but it’s annoying to force fit it in when I’m doing DevOps work or actually attempting to load Windows related images with it. The OS itself is still a nightmare of gigantic proportions compared to spooling up other systems. If one wants to fight with it, that’s great, I don’t really feel a keen desire to fight with it.
  3. Linux == Smaller footprint, more features, let’s not bring up security, is actually used on major systems, large scale systems and super-computers. Windows has less than 2% market share in that space. Even Microsoft is decreasing their reliance on Windows, offering oodles of Linux options.
  4. Windows doesn’t tend to get, run, or have the bleeding edge tech options built for it. Go look at the open source massive distributed systems applications and other excellent leading platforms and tooling that are leading companies into the future. If Windows is involved at all, it’s often an afterthought. :-/
  5. Windows 8 interface. I’m just going to leave that one right there. I like a lot about it, but I’m with Microsoft, even with Windows 10 they’re not trying to push this UI/UX catastrophe any longer.
  6. SSH not built in. End of story.

Don’t get me wrong, the tooling on Windows for doing Windows specific development and even doing crud apps with lots of business rules is spectacular. I’d even bet that the .NET ecosystem does a better job, sometimes dramatically better, than the Java ecosystem when it comes to those types of applications. I however, haven’t built these style of applications in a long while. Whenever I do, Windows might be a prime option, but otherwise I’ll stick to the operating systems that get me into the coding faster, sooner, and with less resistance.

Outside of Windows there are a lot of great Microsoft tools and technologies that I’d love to have on non-Windows operating systems. One of those is F#. Another is Visual Studio, which I’m betting will continue to get better and better. I’d like to have C# (which I do with Xamarin and such) and a whole ton of other scaffolding and crud tools and other things that are available. I just prefer them without Windows.

As I often say, to each their own. Mine just isn’t Windows these days.