So I’ve been doing some browsing around my various Social Media feeds and saw a tweet about the drama surrounding a Pull Request for the Nuget Repository Website to add a tab for how to get a package through Paket. This is evidently big stuff for Microsoft and the makers of Paket alike. But that’s neither here-nor-there. What I’m getting at is that after reading about Paket, I’ve decided to switch to it.
Why would I do such a thing? Isn’t nuget the bomb?
Yes, nuget is quite awesome. However, the one thing that sucks about it is the lack of support for intelligently figuring out what to include in your nuget files. With plain-old-nuget, you have to manage all aspects of your nuspec file yourself, including what files are included and where they go. To overcome this limitation I’ve been using a nuget package called OctoPack. OctoPack is pretty cool. It will figure out the files that need to be included for your project and dutifully include them in your nuget file. It also includes a MS-Build task for creating the Nuget package upon building your project.
Unfortunately, OctoPack has some limitations. If you let it figure out what to package, it only puts those files into the root folder of your target location. This may be fine for an application being deployed through Octopus Deploy, but it is no good for nuget packages heading for a repository for further consumption. To get it to put the correct files in the correct places, you still need to specify the files location in the nuspec file.
So, when I read about Paket I got really excited. Paket has the ability to not only know what files to include, but since it’s targeting developers instead of application deployments, it puts the files in the correct locations for re-use as nuget repository packages.
Additionally, Paket reads a lot of information from your AssemblyInfo.cs file (such as Project Title, version etc.) and automatically populates the package manifest accordingly.CodeProject