fsprojects / paket

A dependency manager for .NET with support for NuGet packages and Git repositories.

Paket

A dependency manager for .NET with support for NuGet packages and git repositories.

Why Paket?

NuGet did not separate out the concept of transitive dependencies. If you install a package into your project and that package has further dependencies then all transitive packages are included in the packages.config. There is no way to tell which packages are only transitive dependencies.

Even more importantly: If two packages reference conflicting versions of a package, NuGet will silently take the latest version (read more). You have no control over this process.

Paket on the other hand maintains this information on a consistent and stable basis within the paket.lock file in the solution root. This file, together with the paket.dependencies file enables you to determine exactly what's happening with your dependencies.

Paket also enables you to reference files directly from git repositories or any http-resource.

For more reasons see the FAQ.

Online resources

• Source code
• Documentation
• Getting started guide
• Download paket.exe
• Download paket.bootstrapper.exe

Troubleshooting and support

• Found a bug or missing a feature? Feed the issue tracker.
• Announcements and related miscellanea through Twitter (@PaketManager)

Prerequisites

Windows

• As of #2664, paket now automatically bootstraps all required dependencies and builds on a clean windows installation.

Linux

• up-to-date Mono (>= 5.0 required, >= 5.2 recommended, just install the latest nightly)
• up-to-date MSBuild (>= 15.0, support for "Directory.Build.props" required)

On most distros, it should be enough to follow this guide and install mono-devel, which contains MSBuild. Note: if the paket build script fails at paket restore just rerun it a few times until it succeeds.

Quick contributing guide

• Fork and clone locally.
• Build the solution with Visual Studio, build.cmd or build.sh.
• Create a topic specific branch in git. Add a nice feature in the code. Do not forget to add tests and/or docs.
• Run build.cmd (build.sh on Mono) to make sure all tests are still passing.
• When built, you'll find the binaries in ./bin which you can then test with locally, to ensure the bug or feature has been successfully implemented.
• Send a Pull Request.

If you want to contribute to the docs then please modify the markdown files in /docs/content and send a pull request. Note, that short description and syntax for each command is generated automatically from the Paket.Commands module.

License

The MIT license

Maintainer(s)

• @forki
• @agross
• @cloudroutine
• @matthid
• @isaacabraham
• @theimowski

The default maintainer account for projects under "fsprojects" is @fsprojectsgit - F# Community Project Incubation Space (repo management)

paket's Issues

Give better error messages when parsing Dependencies file

source "http://nuget.org/api/v2"

nuget "RavenDB.Client" ">= 0"
nuget RavenDB.Server" ">= 0"  // missing "

packages.fsx should support "no nugets" scenario

Consider this packages.fsx:

source "http://nuget.org/api/v2"

Look ma, no dependencies!

paket install yields:

Unhandled Exception: System.Exception: FsiEvaluationSession could not be created.

packages.fsx(3,1): error FS0514: End of file in string begun at or before here

   at [email protected](String message) in D:\Users\agross\Downloads\Paket\src\Paket\Config.fs:line 68
   at Microsoft.FSharp.Core.PrintfImpl.go@523-3[b,c,d](String fmt, Int32 len, FSharpFunc`2 outputChar, FSharpFunc`2 outa, b os, FSharpFunc`2 finalize, FSharpList`1 args, Int32 i)
   at Microsoft.FSharp.Core.PrintfImpl.run@521[b,c,d](FSharpFunc`2 initialize, String fmt, Int32 len, FSharpList`1 args)
   at <StartupCode$FSharp-Core>[email protected](T1 inp)
   at Paket.ConfigHelpers.executeInScript(FSharpFunc`2 executeInScript) in D:\Users\agross\Downloads\Paket\src\Paket\Config.fs:line 68
   at Paket.LockFile.Create(String packageFile) in D:\Users\agross\Downloads\Paket\src\Paket\LockFile.fs:line 53
   at Paket.LockFile.Update(String packageFile, String lockFile) in D:\Users\agross\Downloads\Paket\src\Paket\LockFile.fs:line 58
   at Paket.Process.Install(Boolean regenerate, Boolean force, String packageFile) in D:\Users\agross\Downloads\Paket\src\Paket\Process.fs:line 37
   at <StartupCode$Paket>.$Paket.Program.main@() in D:\Users\agross\Downloads\Paket\src\Paket\Program.fs:line 40

How do we want people to install Paket?

Chocolatey? Homebrew?
What are the cool kids using?

Paket.exe without params should show help

Source items in NuGets, e.g. bootstrap, jquery etc. not handled yet?

I'm using the F# MVC 5 template addin to wizard up a WebApi app (targetting FW 4.5.1).

The bootstrap (v3.2) package (and I think jquery which it depends on too) seems not to be extracting files when listed in the Paket.references.

The bootstrap NuGet has source files 2 levels nested (a fonts folder, some Scripts and some Content) and install seems to ignore them. So I let it and jquery be managed by NuGet (which croaks with a nullref every 2 seconds).

naming suggestion for nuget

May be not every time we will use NuGet as package management system. So I think it is more common to rename 'nuget' into 'repo'. The source of 'repo' is defined at beginning of packages.fsx file.

Improve error message when connection to NuGet server fails

>paket install
Analyzing Dependencies
Unable to connect to the remote server

Which server/URL?

Detect the dll versions based on the referenced .NET Framework version in a ProjectFile

At the moment we install the last framework version of a package in alphabetical order.
This is of course non-sense

Paket should be .NET 4.0

Why? Because we can.

Build timeouts due to download/extract issue

Some of the builds (e.g. https://travis-ci.org/fsprojects/Paket/builds/34470575) get a timeout on mono.
Why is that?

All TravisCI builds: https://travis-ci.org/fsprojects/Paket/builds

We don't see this on windows / AppVeyor: https://ci.appveyor.com/project/SteffenForkmann/paket/history

Support TeamCity feeds

nuget install Microsoft.Rtc.Collaboration-2010 -source http://teamcity/guestAuth/app/nuget/v1/FeedService.svc
Installing 'Microsoft.Rtc.Collaboration-2010 4.0.7577.0'.
Successfully installed 'Microsoft.Rtc.Collaboration-2010 4.0.7577.0'.

source "http://teamcity/guestAuth/app/nuget/v1/FeedService.svc"

nuget "Microsoft.Rtc.Collaboration-2010" "~> 4.0.7577.0"

>Paket.exe install

Unhandled Exception: System.Exception: No package found which matches Microsoft.Rtc.Collaboration-2010 Range ({Major = 4;
        Minor = 0;
        Patch = 7577;
        PreRelease = null;
        Build = "0";
        Original = Some "4.0.7577.0";},{Major = 5;
                                        Minor = 0;
                                        Patch = 0;
                                        PreRelease = null;
                                        Build = "0";
                                        Original = Some "5.0.0.0";}).
Version available: []

Not all tests are run during build

for example the test Paket.FilterVersionSpecs.should filter by range is not reported to be run

Implement nuget version ranges in Nuget.fs

http://docs.nuget.org/docs/reference/versioning

Don't forget to add tests in NugetVersionRangeSpecs.fs

Check hash of downloaded nuget package

ArgumentException: The input sequence was empty. when installing SpecFlow.NUnit

Consider this packages.fsx:

source "http://nuget.org/api/v2"

nuget "SpecFlow.NUnit" "~> 1.1"

paket install yields:

Unhandled Exception: System.ArgumentException: The input sequence was empty.
Parameter name: source
   at Paket.Resolver.analyzeGraph@45(IDiscovery discovery, FSharpMap`2 processed, FSharpMap`2 dependencies) in D:\Users\agross\Downloads\Paket\src\Paket\Resolver.fs:line 67
   at Paket.LockFile.Update(String packageFile, String lockFile) in D:\Users\agross\Downloads\Paket\src\Paket\LockFile.fs:line 58
   at Paket.Process.Install(Boolean regenerate, Boolean force, String packageFile) in D:\Users\agross\Downloads\Paket\src\Paket\Process.fs:line 37
   at <StartupCode$Paket>.$Paket.Program.main@() in D:\Users\agross\Downloads\Paket\src\Paket\Program.fs:line 40

Installing Rx-Main yields "downloaded package hash does not match nuget"

Consider this packages.fsx:

source "http://nuget.org/api/v2"

nuget "Rx-Main" "~> 2.2"

paket install yields:

Lockfile written to D:\Users\agross\Downloads\packages.lock
Rx-Core 2.2.5 already downloaded
Rx-Main 2.2.5 already downloaded
Rx-Linq 2.2.5 already downloaded
Rx-Interfaces 2.2.5 already downloaded
Downloading Rx-PlatformServices 2.3
Rx-Main 2.2.5 unzipped to D:\Users\agross\Downloads\packages\Rx-Main
Rx-Interfaces 2.2.5 unzipped to D:\Users\agross\Downloads\packages\Rx-Interfaces
Rx-Core 2.2.5 unzipped to D:\Users\agross\Downloads\packages\Rx-Core
Rx-Linq 2.2.5 unzipped to D:\Users\agross\Downloads\packages\Rx-Linq

Unhandled Exception: System.Exception: downloaded package hash does not match nuget
   at Microsoft.FSharp.Control.AsyncBuilderImpl.commit[a](Result`1 res)
   at Microsoft.FSharp.Control.CancellationTokenOps.RunSynchronously[a](CancellationToken token, FSharpAsync`1 computation, FSharpOption`1 timeout)
   at Microsoft.FSharp.Control.FSharpAsync.RunSynchronously[T](FSharpAsync`1 computation, FSharpOption`1 timeout, FSharpOption`1 cancellationToken)
   at Paket.Process.Install(Boolean regenerate, Boolean force, String packageFile) in D:\Users\agross\Downloads\Paket\src\Paket\Process.fs:line 38
   at <StartupCode$Paket>.$Paket.Program.main@() in D:\Users\agross\Downloads\Paket\src\Paket\Program.fs:line 44

Can Paket resolve dependencies across multiple sources?

Pessimistic version constraint (~>) should support versions that are not in the feed

I reference a nuget with ~> 4.0 which translates to 4.0 <= x < 5.0. The 4.0 package never existed and will never exist. I should be able to install the existing package in version 4.0.7577.0 though.

Unhandled Exception: System.Exception: No package found which matches Microsoft.Rtc.Collaboration-2010 Range ({Major = 4;
        Minor = 0;
        Patch = 0;
        PreRelease = null;
        Build = "";
        Original = Some "4.0";},{Major = 5;
                                 Minor = 0;
                                 Patch = 0;
                                 PreRelease = null;
                                 Build = "";
                                 Original = Some "5.0";}).

Ruby's bundler supports that scenario just fine:
Gemfile:

source :rubygems

gem "rake", "~> 0.1"

>bundle install
Fetching gem metadata from http://rubygems.org/..
Resolving dependencies...
Using rake 0.9.6
Using bundler 1.6.5
Your bundle is complete!
Use `bundle show [gemname]` to see where a bundled gem is installed.

For reference, rake 0.1 never was released.

Download package should download again if package is corrupt

In https://github.com/fsprojects/Paket/blob/master/src/Paket/Nuget.fs#L98 we check if the file exists and if it has data.

We should check the hash instead.

Allow ??projs without package definition files

Useful when you only need e.g. NUnit.Runners (containing only tools)

Unhandled Exception: System.Exception: Package config file not found for Project <somewhere>\Presence\source\Host\Host-2013.csproj
   at [email protected](String message) in D:\Users\agross\Downloads\Paket\src\Paket\Process.fs:line 31
   at Microsoft.FSharp.Core.PrintfImpl.go@523-3[b,c,d](String fmt, Int32 len, FSharpFunc`2 outputChar, FSharpFunc`2 outa, b os, FSharpFunc`2 finalize, FSharpList`1 args, Int32 i)
   at Microsoft.FSharp.Core.PrintfImpl.run@521[b,c,d](FSharpFunc`2 initialize, String fmt, Int32 len, FSharpList`1 args)
   at <StartupCode$FSharp-Core>[email protected](T1 inp)
   at Paket.Process.Install(Boolean regenerate, Boolean force, String packageFile) in D:\Users\agross\Downloads\Paket\src\Paket\Process.fs:line 42
   at <StartupCode$Paket>.$Paket.Program.main@() in D:\Users\agross\Downloads\Paket\src\Paket\Program.fs:line 40

Paket.exe install should detect updated package.fsx

Say you have dependency A installed (per packages.fsx, packages.lock was created). Now you add dependency B to packages.fsx. Paket.exe install should install dependency B and update the lockfile.

Implement: Topological sort of lock file

Strategies for package selection...

As I briefly mentioned on Twitter, I immediately thought when seeing this (again) about a project we used NuGet for internally at a client.

In essence, we used NuGet as a deployment mechanism at runtime - a host node would be told to run some package and would install and spin it up using the dependencies as determined by NuGet. But in actual fact we had to patch the dependency resolution algo to make it work according to a Semantic Versioning approach, as whenever we instantiated a new instance of some packaged process, we wanted it to use the latest compatible libs. So we ended up with our own hacked dependency resolution. (And of course we also had to patch assembly resolution inside these processes so it would know how to find them within packages, etc.)

While it's likely far outside the scope of what you're looking at doing with Paket, it would be interesting to see if it's possible to build a core which is capable of use as both a static (build/compile) time package manager, and potentially a dynamic one at runtime.

"Resolve from Lock file" could be one strategy, "Resolve using Semantic Versions" another.

There's nothing really existent in the .net space about a more dynamic deployment platform. We built one to some degree, but NuGet was one of the major pain points - but without real alternative at the time. It might be nice to take an even broader look at how package/dependency management could fit in to less static systems (some days I feel like I should just use Erlang, but then I look at the type system and...)

Anyway, that's probably a poorly explained ramble, it's late-ish. Possibly someone like @mavnn or @kjnilsson could add to it to make more sense...

MatchFailureException when installing Nancy.Serialization.JsonNet

Consider this packages.fsx:

source "http://nuget.org/api/v2"

nuget "Nancy.Serialization.JsonNet" "~> 0.18"

paket install yields:

Unhandled Exception: Microsoft.FSharp.Core.MatchFailureException: The match cases were incomplete
   at Paket.VersionRange.IsInRange(SemVerInfo version) in D:\Users\agross\Downloads\Paket\src\Paket\BasicTypes.fs:line 16
   at Microsoft.FSharp.Collections.IEnumerator.next@178[T](FSharpFunc`2 f, IEnumerator`1 e, FSharpRef`1 started, Unit unitVar0)
   at [e-mail]-Collections-IEnumerator-MoveNext()
   at [email protected](b& )
   at Microsoft.FSharp.Collections.IEnumerator.MapEnumerator`1.System-Collections-IEnumerator-MoveNext()
   at Paket.Resolver.analyzeGraph@45(IDiscovery discovery, FSharpMap`2 processed, FSharpMap`2 dependencies) in D:\Users\agross\Downloads\Paket\src\Paket\Resolver.fs:line 67
   at Paket.LockFile.Update(String packageFile, String lockFile) in D:\Users\agross\Downloads\Paket\src\Paket\LockFile.fs:line 58
   at Paket.Process.Install(Boolean regenerate, Boolean force, String packageFile) in D:\Users\agross\Downloads\Paket\src\Paket\Process.fs:line 37
   at <StartupCode$Paket>.$Paket.Program.main@() in D:\Users\agross\Downloads\Paket\src\Paket\Program.fs:line 40

Do not save project files if we didn't modify them

Otherwise VS will ask to reload. Which is annoying

Allow to depend on simple F# or C# code files

In F# land we often want to share one or two F# files between multiple repositories. It would be cool to have support for that.

Not sure if nuget is the best way for that.

Cache nupkg download to the same location as Nuget.exe does

At the moment we download all nupkg to ./packages. This was only for testing purposes. We should download to the same place as Nuget.exe. We should skip download it the package version already exists at this place.

Pessimistic version constraint computes incorrect version range

source "http://nuget.org/api/v2"

nuget "Castle.Windsor-log4net" "~> 3.2.0.0"

This translates to 3.2.0.0 <= x < 3.2.1.0 so it should install Castle.Windsor-log4net 3.2.0.1. It installs 3.3.0, though.

Some more specs:

"~> 1.2.3.4" -> 1.2.3.4 <= x < 1.2.4.0
"~> 1.2.3"   -> 1.2.3.0 <= x < 1.2.4.0
"~> 1.2"     -> 1.2.0.0 <= x < 1.3.0.0
"~> 1"       -> 1.0.0.0 <= x < 2.0.0.0

I'm not really sure if we could scrap the trailing zeros. We need to investigate if nuget considers 2.0 equal to 2.0.0 and 2.0.0.0 and which of them would be considered 'higher' versions.

Support path sources

Some people might host their nugets in a share or test using a file system folder.

source "C:\Nugets"
source "\\server\nugets"

Low-priority, IMHO.

We need to write the NuGet package hash into the lockfile

We don't want to call OData during normal install process

Support for 3rd party package managers

I've noticed that Packet offers a lot nicer and more useful way do manage project dependencies than what NuGet provides, I would like to be able to use it with other package managers.

Example: When you want to provide support web-oriented projects with many client-side libraries, you may still rely on NuGet, but from my own experience bower and npm are much richer in this matter.

So my question is - are you guys thinking about providing layer for third party package managers?

Implement "IsInRange" for all VersionRanges

https://github.com/fsprojects/Paket/blob/master/src/Paket/BasicTypes.fs#L21

Tests should go to: https://github.com/fsprojects/Paket/blob/master/tests/Paket.Tests/FilterVersionSpecs.fs

Change the file names to new naming idea

As discussed with @agross we want:

Dependencies
Dependencies.lock
References.list

Text snippet:

The definitions in your Dependencies file are taken to compute the list of all depedencies 
which is written to Dependencies.lock. 
Ýou may have a References.list file next to your VS projects to have Paket 
automatically add references for the package IDs noted in that file.

Leverage type system to restrict invalid version specification

Having a version specification syntax hidden in opaque strings is a shame given a powerful type system of F#. Having a strongly typed DSL in F# would make API more discoverable. Carefully chosen discriminated unions may provide better type safety than regular records with int fields. ~> 3.1 is not same as ~> 3.1.0.

Consider something like this: https://gist.github.com/shishkin/f4b4cb9d8a9d3959fccc.

A Nuget type provider would be even better. Thoughts?

Cache all NuGet data

The Nuget OData lookup is slow and complicated. We should cache all retrieved information in JSON files.

Allow OldestMatching resolution strategy

In order to be backwards compatibility with nuget we should allow a "oldest package that match flag in the packages.fsx

Not sure what the best solution is but I think of something like:

  nuget "FSharp.Formatting" "~> 2.2 LowestMatching" 

Wrap download in async and download in parallel

Download is very naive at the moment, but we should parallelize and cache from the start.

Later we will parallelize the whole install (which doesn't exist yet)

Direct dependency does not influence/override indirect dependency resolution

packages.fsx:

source "http://nuget.org/api/v2"

nuget "Castle.Core" "= 3.2.0"
nuget "Castle.Windsor-log4net" "= 3.2.0.1"

packages.lock:

NUGET
  remote: http://nuget.org/api/v2
  specs:
    Castle.Core (3.2.0)
    Castle.Core-log4net (3.3.0)
    Castle.LoggingFacility (3.3.0)
    Castle.Windsor (3.3.0)
    Castle.Windsor-log4net (3.2.0.1)
    log4net (1.2.10)

• Castle.Windsor-log4net 3.2.0.1 has a dependency to Castle.Core-log4net >= 3.2.0
• Castle.Core-log4net 3.3.0 has a dependency to Castle.Core >= 3.3.0
• Castle.Core-log4net 3.2.0 has a dependency to Castle.Core >= 3.2.0

Paket should select Castle.Core-log4net 3.2.0 to satisfy our direct dependency nuget "Castle.Core" "= 3.2.0". It does select Castle.Core-log4net 3.2.0 though, leading to build and/or runtime errors.

Nuget-style pessimistic version constraint isn't honored with other nugets when another nuget has the same indirect dependency

Direct dependency of N.B.Windsor is specified explicitly:

source "http://nuget.org/api/v2"

nuget "Castle.Windsor" "!>= 0"
nuget "Nancy.Bootstrappers.Windsor" "!~> 0.23"

NUGET
  remote: http://nuget.org/api/v2
  specs:
    Castle.Core (3.3.0)
    Castle.Windsor (3.3.0)  // should be 3.2.1
      Castle.Core (>= 3.3.0)
    Nancy (0.23.2)
    Nancy.Bootstrappers.Windsor (0.23.2)
      Nancy (>= 0.23.2)
      Castle.Windsor (>= 3.2.1)

Direct dependency of N.B.Windsor is specified indirectly through C.W-log4net:

source "http://nuget.org/api/v2"

nuget "Castle.Windsor-log4net" "!>= 0"
nuget "Nancy.Bootstrappers.Windsor" "!~> 0.23"

NUGET
  remote: http://nuget.org/api/v2
  specs:
    Castle.Core (3.3.0)
    Castle.Core-log4net (3.3.0)
      Castle.Core (>= 3.3.0)
      log4net (1.2.10)
    Castle.LoggingFacility (3.3.0)
      Castle.Core (>= 3.3.0)
      Castle.Windsor (>= 3.3.0)
    Castle.Windsor (3.3.0)  // should be 3.2.1
      Castle.Core (>= 3.3.0)
    Castle.Windsor-log4net (3.3.0)
      Castle.Core-log4net (>= 3.3.0)
      Castle.LoggingFacility (>= 3.3.0)
    Nancy (0.23.2)
    Nancy.Bootstrappers.Windsor (0.23.2)
      Nancy (>= 0.23.2)
      Castle.Windsor (>= 3.2.1)
    log4net (1.2.10)

Store indirect dependencies in the lockfile

It makes researching package version inconsistencies far easier. This will help users to migrate to paket.

We need support for NuGet prereleases

Dependency graph may become invalid

source "http://nuget.org/api/v2"

// provides Castle.Windsor (3.2.0) through nuget's 'min' strategy
nuget "Castle.Windsor-log4net" "!= 3.2"

// requires Castle.Windsor (>= 3.2.1)
nuget "Nancy.Bootstrappers.Windsor" "~> 0.23"

The computed graph is inconsistent:

NUGET
  remote: http://nuget.org/api/v2
  specs:
    Castle.Core (3.2.0)
    Castle.Core-log4net (3.2.0)
      Castle.Core (>= 3.2.0)
      log4net (1.2.10)
    Castle.LoggingFacility (3.2.0)
      Castle.Core (>= 3.2.0)
      Castle.Windsor (>= 3.2.0)
    Castle.Windsor (3.2.0)                       // !!!
      Castle.Core (>= 3.2.0)
    Castle.Windsor-log4net (3.2.0)
      Castle.Core-log4net (>= 3.2.0)
      Castle.LoggingFacility (>= 3.2.0)
    Nancy (0.23.2)
    Nancy.Bootstrappers.Windsor (0.23.2)
      Nancy (>= 0.23.2)
      Castle.Windsor (>= 3.2.1)                  // !!!
    log4net (1.2.10)

Paket needs a logo

Firstly let's look on available images.
What do you like?

Option 1:

Option 2:

Option 3:

Option 4:

Option 5:

Option 6:

Option 7:

Option 8:

Option 9:

Option 10:

Option 11:

Option 12:

Option 13:

Option 14:

Option 15:

Option 16:

Option 17:

Option 18:

Option 19:

Option 20:

Option 21:

Option 22:

Option 23:

Option 24:

Option 25:

Option 26:

Option 27:

Option 28:

Option 29:

Option 30:

Option 31(*):

Use SharpZipLib

http://stackoverflow.com/questions/24700424/error-when-creating-zip-files-in-mono-using-system-io-compression

GenerateDocs fails, but build succeeds

Starting Target: GenerateDocs (==> CleanDocs)
fsharpi --define:RELEASE generate.fsx


/Users/serega/Code/oss/Paket/docs/tools/generate.fsx(25,1): warning FS0211: The search directory '/Users/serega/Code/oss/Paket/docs/tools/../../packages/FSharp.Formatting.2.4.1/lib/net40' could not be found


/Users/serega/Code/oss/Paket/docs/tools/generate.fsx(27,1): warning FS0211: The search directory '/Users/serega/Code/oss/Paket/docs/tools/../../packages/FSharp.Compiler.Service.0.0.36/lib/net40' could not be found


/Users/serega/Code/oss/Paket/docs/tools/generate.fsx(32,1): error FS0078: Unable to find the file 'FSharp.Literate.dll' in any of
 /Library/Frameworks/Mono.framework/Versions/3.6.0/lib/mono/4.5
 /Users/serega/Code/oss/Paket/docs/tools/../../packages/RazorEngine.3.3.0/lib/net40
 /Users/serega/Code/oss/Paket/docs/tools
 /Library/Frameworks/Mono.framework/Versions/3.6.0/lib/mono/4.0/
Finished Target: GenerateDocs
Starting Target: All (==> GenerateDocs)
Finished Target: All

---------------------------------------------------------------------
Build Time Report
---------------------------------------------------------------------
Target            Duration
------            --------
Clean             00:00:00.0043777
RestorePackages   00:05:58.9508163
AssemblyInfo      00:00:00.0149502
Build             00:00:17.0877105
RunTests          00:00:07.6504655
CleanDocs         00:00:00.0005902
GenerateDocs      00:00:04.1767583
All               00:00:00.0002612
Total:            00:06:27.9506267
Status:           Ok
---------------------------------------------------------------------

Replace lockfile format with JSON?

We can simplify the code for reading and writing of the lockfile if we create a lockfile record and just use Newtonsoft JSON to handle the serialization (since v6 it has native support for F#).

Cleanup paths after NuGet package extraction

should look as

Should the project's package file support direct dependencies only?

Currently there's the idea to use a project-specific packages file to define the subset of package IDs that paket needs to reference in the respective project. This is to have any number of dependencies in the packages.fsx but only reference the test-specific subset among these for test projects.

Definition direct dependency: A dependency that is declared in packages.fsx
Definition indirect dependency: A dependency of a direct dependency. Indirect dependencies might change with future releases of direct dependencies (adding or removing indirect dependencies).

Both direct and indirect dependencies and their calculated versions will to be downloaded to <packages.fsx location>/packages/ and saved to packages.lock.

My question is whether it's a good idea to restrict the dependencies that are allowed in the project-specific packages file to direct dependencies.

Now on to the discussion, assuming there is no packages.lock (see below why this is a good idea):

Restricting packages to direct dependencies

Pros

• The user must be very explicit what packages all of the projects need
• Future package updates of direct dependencies removing indirect dependencies won't cause any harm. Paket will still download them according to packages.fsx, thus making them available.

Cons

• If the user requires an indirect dependency that is downloaded through virtue of the fact that a direct dependency requires it, the indirect dependency would have to become a direct dependency for it to be allowed in the project-specific packages file. I.e. both the direct and the indirect dependencies need to be put in packages.fsx.

Allowing direct and indirect dependencies

Pros

• The packages.fsx might become a bit shorter, listing only high-level direct dependencies.

Cons

• Future updates of direct dependency removing indirect dependencies will cause paket to not download it, thereby break the build. The user would then have to update packages.fsx to make the previously-indirect dependency a direct dependency.

Why not having a lockfile sometimes is a good idea

In Ruby (with bundler) there is the notion that library developers should not check in their Gemfile.lock files (= packages.lock). The reason is that reproducible builds are generally not that much important for libraries and that you rather want to know whether the library still works with the latest dependencies according to the version constrains in the Gemfile (= packages.fsx).

This makes it very easy to just rerun bundle install and your test suite (even in CI) from time to time without the need to change any files.

I think for .NET libraries the same pattern may emerge, with services like https://gemnasium.com/ that check your libraries' dependencies weekly and notify you about (semver) breaking changes in your libraries' dependency set.

For applications, on the other hand, the situation is a bit different. For them you want reproducible builds, regardless of dependency updates (according to `packages.fsx´). This is where the lockfile comes into play. It records the fact that you proved your app works against a specific set of dependencies in specific versions. Using the lockfile enables you to recreate the same runtime environment over and over again.

You can read more about the way Ruby handles this here:
http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
http://bundler.io/v1.3/rationale.html#checking-your-code-into-version-control

I hope I could get my point across. Looking forward to your feedback!

SharpZipLib.FastZip doesn't support Mono

I'm really interested in this project, I think a better package ecosystem could do a lot for F# on *nix.

I cloned and ran ./build.sh. After building I looked for a paket command as mentioned on https://fsprojects.github.io/Paket/, but there isn't one in the repo.

I also tried running the .exe directly, but got an exception:

$ mono bin/Paket.Core.exe
Missing method Install in assembly /auto/users/robnea/dev/Paket/bin/Paket.Core.exe, type Paket.Process

Unhandled Exception:
System.TypeLoadException: Could not load type 'Paket.Process' from assembly 'Paket.Core'.
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: Could not load type 'Paket.Process' from assembly 'Paket.Core'.

Am I misunderstanding something? I'd like to help make sure it works on Linux.

Detect more (all?) framework versions from NuGet lib paths

In order to install packages correctly we have to map NuGet lib paths to Framework versions.

Also please add some tests at https://github.com/fsprojects/Paket/blob/master/tests/Paket.Tests/ProjectFileConditionSpecs.fs