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.
