Paket is a package manager for .NET languages, intended to be an alternative for the popular NuGet. InfoQ reached out with Steffen Forkmann, co-creator of the project, to learn more about Paket's origin and features.
InfoQ: What are the main drivers for creating a new package manager in .NET, considering the wide adoption of NuGet?
Steffen Forkmann: While we really liked using NuGet packages and contributing to the ecosystem we also felt a lot of pain in some specific areas. Most of the problems were due to the fact that NuGet’s philosophy was “it’s just a Visual Studio macro” . This means nuget.exe wasn’t seen as a real dependency manager, but as a macro which allows you to download packages and reference them from within Visual Studio projects. For many professional software development projects this idea of hiding dependencies creates a lot of pain. Together with the fact that nuget.exe stores packages with the version number in the path and no global overview, things quickly become difficult to manage in all but the simplest projects.
At the time when we started Paket, we had already gone through a couple of discussions about changing the NuGet model, but the NuGet team made it very clear that this was not the way they wanted to go. Since most of Paket’s additions were breaking, there was no interest in bringing these changes into nuget.exe.
So Alexander Gross and I started to create a new project in order to solve our own dependency management issues. The scope of the project was only to replace nuget.exe, i.e. only the client side of NuGet. We also formulated the following project principles:
- Integrate into the existing NuGet ecosystem
- Make things work with minimal tooling (plain text files)
- Make it work on all platforms
- Automate everything
- Create a nice community
InfoQ: How does dependency resolution works in Paket? How does it handle conflicts?
SF: Paket uses the paket.dependencies file to specify project dependencies. Usually only direct dependencies are specified and often a broad range of package versions is allowed. During “paket install” Paket needs to figure out concrete versions of the specified packages and their transitive dependencies. These versions are then persisted to the paket.lock file.
In order to figure out the concrete versions Paket needs to solve the following constraint satisfaction problem: Select the latest version for each of the packages in the paket.dependencies file, plus all their transitive dependencies, such that all version constraints are satisfied.
In general, more than one solution to this problem can exist and the resolver will take the first solution that it finds. An article on Paket's website explains the resolution process in more details.
If the resolver can't find a valid resolution, then it needs to report an error to the user. Since the search tree can be very large and might contain lots of different kinds of failures, it will only report the last conflict that it can't resolve and also some information about the origin of this conflict.
In contrast to nuget.exe Paket only allows you to use one version of the same package in the whole solution. So you can’t accidentally introduce version conflicts by referencing different versions of the same package in different projects. If you really need more than one version of the same package then you can do so by using dependency groups.
InfoQ: Does Paket support all .NET languages? (Do you have any statistics about usage in C# and F# projects?)
SF: Yes, Paket supports basically all .NET languages – even things like Nemerle. Most of our users are C# enterprise companies, but since we don’t track our users we don’t have any statistics about that.
InfoQ: What are the features you would like to see add to Paket in the future? Which one do users request the most?
SF: Currently we’re working on Paket 3.0 which will come with a big new feature. The basic idea is that you can reference a Git repository in your paket.dependencies file, and Paket will clone and build the project for you. If the build generates NuGet packages then these can be used as an additional source.
The most requested feature right now is support for CoreCLR / DNX projects, but for this we need would some changes in the project.json model. Unfortunately right now we haven’t yet come up with a satisfactory solution to this yet, but we’re hoping that we can work with the Microsoft team to solve this issue.
InfoQ: Anything you would like to add?
I would like to thank all contributors and the whole Paket community for making the project such a big success in such short time frame. It wouldn't have be possible without all that help.
Paket is an open source project available on GitHub.Documrentation can be found on FsProjects.
Community comments
Interesting
by Mac Noodle,
Re: Interesting
by Rahul Ballal,
Re: Interesting
by Pierre-Luc Maheu,
Re: Interesting
by Mac Noodle,
Interesting
by Mac Noodle,
Your message is awaiting moderation. Thank you for participating in the discussion.
I'll have to check it out. While Nuget does do some useful things, it does not go far enough. It needs to do what Gradle/Maven do in the Java world. It is sad that NPanday died off. The problem though might really be with VS.NET. Resources grabbed by the resource manager should NOT be part of the project until it is built for deployment. Additionally, it should be obvious as to which resources were added manually or via the build tool. I think i read this is something Paket solves.
Re: Interesting
by Rahul Ballal,
Your message is awaiting moderation. Thank you for participating in the discussion.
I am at the other side of the spectrum. I don't like to mix dependency management with build. Nuget + msbuild or npm +gulp instead of kitchen sinks like gradle or maven.
Re: Interesting
by Pierre-Luc Maheu,
Your message is awaiting moderation. Thank you for participating in the discussion.
Another possible combo that is being used more and more is Paket and Fake. Have you tried Fake?
Re: Interesting
by Mac Noodle,
Your message is awaiting moderation. Thank you for participating in the discussion.
You have the right to not like something. It does not make it make what you don't like a worse solution.
They problem is that they go hand in hand. If you separate them, then you have always include (embed) your dependencies prior to build. When you pull in new or update dependencies, you have to do build. This becomes even more problematic when you have multiple projects using the same dependencies.
The reason they are separated in MS land is because of what typically happens there. MS only provides a partial solution and thus someone has to pick up the rest. Also, my opinion is that VS.NET is part of the problem and why using something like Gradle/Maven with it seems less optimal.
In the Java world, there are tools like MSbuild and Nuget. But they have very low usage. And there is a good reason. Maven and Gradle are much better solutions.