Search code examples
f#-fakepaket

Are Paket dependency groups more than just a way to solve version conflicts?

The paket.dependencies sample file produced when running dotnet new fake currently looks like:

// [ FAKE GROUP ]
group Build
    source https://api.nuget.org/v3/index.json
    nuget Fake.DotNet.Cli
    nuget Fake.IO.FileSystem
    nuget Fake.Core.Target

I understand how dependency groups can be used to solve version conflicts, however it seems unnecessary to introduce them until an actual version conflict situation arises.

What is the semantic of the Build group here and why not just have the three dependencies under the Main default group? The same reflection applies to the Test group in the Paket documentation example.

Can one elaborate on reasons for segregating dependencies in groups in the case of no version conflicts? Maybe explaining a bit more the rationale behind the Build and Test groups?

Solution

  • As I have basically introduced that split for FAKE 5:

    The reasoning is that one set of the dependencies is used at BUILD-time (ie when running the build script) and one is for your project RUN-time. It is completely valid to have a different set of dependencies for those two.

    Consider the following scenario: You use the FSharp.Formatting (FSF, a markdown parser) project in your build process to generate API documentation and in your project to generate websites. Now you want to update the API documentation by updating FSF but you cannot upgrade FSF in your project for compatibility reasons. With the separation between BUILD and RUN-time this is not a problem and you can see them as "different" dependencies in different versions.

    I'd like to see that approach similar to how node separates dependencies and dev-dependencies

    Regarding the split between RUN and TEST: Personally I'm not a huge fan. I can see how people want to separate their dependencies but paket currently doesn't "really" support that scenario and you can indeed run into issues with that approach. My current suggestion would be to not split between RUN and TEST and manage them in a single group.

    To properly split between RUN & TEST paket would need a new feature to reference another group:

    group Run source https://api.nuget.org/v3/index.json nuget MyDep1 group Test reference_group Run source https://api.nuget.org/v3/index.json nuget MyRunner1

    Similar to the external lock-file feature: https://github.com/fsprojects/Paket/pull/3062#issuecomment-367658114