What benefits do FAKE and PAKET provide over traditional ways?

I’m pretty new to F# and I’m trying to build something using Saturn framework. They’re using ProjectScaffold and in turn FAKE for building, paket for package management.

Why do you think these 2 utilities would help me over traditional ways? What problems do they solve? I did not find any answer on their official websites so I thought I should start a discussion here.

EDIT: By traditional ways I mean running dotnet build and dotnet restore commands.

EDIT 2: I found these 2 related articles which talk about having a custom build system in every project:

http://zutubi.com/products/pulse/articles/buildenlightenment/
https://blog.codinghorror.com/the-f5-key-is-not-a-build-process/

2 Likes

At least for Paket this is a question that has been addressed in the FAQ: https://fsprojects.github.io/Paket/faq.html#I-do-not-understand-why-I-need-Paket-to-manage-my-packages-Why-can-t-I-just-use-NuGet-exe-and-packages-config

1 Like

It looks like to me they both offer more customisation than the standard options, which becomes increasingly important if your project gets large and complicated. Paket allows managing diverse sets of dependencies for example, avoiding (or allowing you to avoid) the annoying version mismatch errors you get with Nuget when you have multiple projects referencing the same library, but different versions.

My personal approach is that if you use dotnet core, just stick with the defaults until you have a need for something more customisable: all my F# work uses MSBuild and Nuget without issue. But I also do most of my F# dev at the low-to-medium size: rarely more than two or three projects, and only half a dozen nuget dependencies (I use CoreRT a bit, and more dependencies means more reflection and more rd.xml issues).

2 Likes

TLDR version:
Paket works really hard to offer “reproducible builds”.
FAKE offers single point of entry for entire build automation.

Both of those aspects are extremely valuable when working with others and are available in every modern ecosystem. They predate dotnet and go above and beyond the capabilities of dotnet.

1 Like

Basic advice to beginners: ignore these projects. These are for advanced use when you have sophisticated build needs (FAKE) or if you run into limitations of Nuget (Paket).

2 Likes

One caveat to @charlesroddie’s advice(which is sound): if scripts are a large part of your work flow you’ll find that paket if very helpful. You can have it generate an fsx file with your dependencies in proper include order and forget the painful path munging that you used to do.

In addition, if distribution of scripts is a concern, FAKE 5 is a fantastic script runner that has performance benefits over fsi when used, laregly due to script compilation and caching.

1 Like

Thank you all for the answers.

Beginners like me, haven’t really run into any nuget package version conflicts. I guess I’ll just go with FAKE and PAKET because I already know the traditional ways. They seem very cool utilities to learn.

Thanks! I completely missed that. I feel dumb now.

I also did a blog series on Paket last year here. It’s a little out of date now (it didn’t really address how Paket works in .NET Core land) but covers the main benefits that Paket brings.

2 Likes

Awesome! Thanks for sharing the link.

Yeah, I think the main question is what Paket actually does with the new project system with . Advantages with the old style project system are pretty clear already, but I figure how the new style system works are pretty opaque to lots of folks (can’t go with “it works magically” when you have larger source trees).

It provides the same benefits as before. If anything, it provides more, since the new PackageReference doesn’t let you lock transitives at all, which you at least had with the packages.config file to a certain degree. Paket integrates pretty great with the new project system - and there’s no need to rewrite csproj / fsproj files with references nodes any more either.

1 Like