Create a "use exactly this" operator in order to override package conflicts

[forki]

Things like fsprojects/FSharp.Formatting#203 are probably never really supported in Paket.

I propose a new operator for the paket.dependencies file

nuget Microsoft.AspNet.Razor == 2.0.30506.0

This operator will force the resolver to install exactly this package version and suppresses errors in version conflicts.

It's not exactly the same but it gives a way out for some of the nasty things nuget packages can do.

[forki]

@agross @ilkerde

I'm open for other syntax than ==

[agross]

I'm OK with ==

Some more ideas:

• === JavaScript-style "exactly"
• ?= "in case of questions, use this one"

The operator must support !, e.g. !==, to use NuGet-style dependency resolution of Razor.

Regardless of the syntax, the developer is responsible for creating the assembly binding redirect in his app.configs.

[matthid]

But this will make it a big pain for people who want to support different kind of builds (for different platforms). For example imagine you want to start to support a net45 build in FSharp.Formatting, then with this "fix" you will always reference the oldest package which will hurt you directly or the users of this library for no good reason (Still having bugs that are already fixed for example).

As Nuget supports this and real Nuget-Packages are using it and Paket "supports" Nuget, Paket should therefore support dependency groups no matter what.
The situation where such groups are used are always a pain but the "nuget way" at least describes exactly what's going on within the package. (A nuget package contains different builds, different builds -> different dependencies).

I think with this solution Paket can't be used in such an environment and people will stop using it if the only supported solution is using the old versions. Paket in the current form is actually perfectly suitable to make .fsproj and .csproj files supporting multiple targets, the only thing that has to be done is to make a packet.lock files for each target (and use the right nuget reference group)?

[forki]

Paket doesn't "support Nuget". We are not a nuget wrapper or something like this. We have our own ideas of dependency management and we want to improve the situation. Making things 100% compatible to all the hacks is not our goal. Actually I think this would make our goal impossible.

Paket in the current form is actually perfectly suitable to make .fsproj and .csproj files supporting multiple targets

that's not true. we would need to install both versions in the packages and therefor add version numbers to the path. That's not going to happen. Sorry.

imagine you want to start to support a net45 build in FSharp.Formatting

yes that would hurt. But nobody wants this at this point. It's just not an issue today.

We will probably find a better way in the future, but I don't think conditional dependencies is the right solution. We need a bit more thinking ....

[matthid]

we would need to install both versions in the packages and therefor add version numbers to the path.

Yep, or using the platform in the path ( deps/net40/package, deps/net45/package ).

That's not going to happen. Sorry.

No need to be sorry, just my 2 cents :)

It's just not an issue today.

nobody wants this at this point

It is an issue, maybe not for FSharp.Formatting (which was only an example). I sure would like to use Paket but this is a issue for me.

[forki]

Using platform in path might actually work. Good idea.
On Oct 6, 2014 12:00 PM, "matthid" notifications@github.com wrote:

we would need to install both versions in the packages and therefor add
version numbers to the path.

Yep, or using the platform in the path ( deps/net40/package,
deps/net45/package ).

That's not going to happen. Sorry.

No need to be sorry, just my 2 cents :)

It's just not an issue today.

nobody wants this at this point

It is an issue, maybe not for FSharp.Formatting (which was only an
example). I sure would like to use Paket but this is a issue for me.

—
Reply to this email directly or view it on GitHub
#220 (comment).

[forki]

Short term goal: implement the == operator to make the workaround possible.

Long term goal: look if we can use framework in package path. But this would come after the new install model is ready.

Everybody agrees?

[agross]

👍

[ilkerde]

+1 for the operator workaround and even agreement on the "framework in package path". However, I strongly suggest to abstract the framework relation of the dependency into the concept of groups, as already suggested/discussed at #140 and partly this big saga #154 (side note: I really don't like naming the groups "pakets" in #154).

Even our initial discussion about groups at #116 shows us in retrospect: we can make use of groups in several contexts/use cases.

[forki]

Could you please describe how groups would help here?
On Oct 6, 2014 9:22 PM, "ilkerde" notifications@github.com wrote:

+1 for the operator workaround and even agreement on the "framework in
package path". However, I strongly suggest to abstract the framework
relation of the dependency into the concept of groups, as already
suggested/discussed at #140
#140 and partly this big saga
#154 #154 (side note: I
really don't like naming the groups "pakets" in #154
#154).

Even our initial discussion about groups at #116
#116 shows us in retrospect:
we can make use of groups in several contexts/use cases.

—
Reply to this email directly or view it on GitHub
#220 (comment).

[ilkerde]

We could introduce the concept of a group acting as constraint boundary. In plain old english: other group, other constraints. On FS level, we could easily scope this using folder. The actual purpose of the group could be to reflect differing constraints for different framework versions (or platforms, or maybe even environments). Does this makes sense a little?

[forki]

But this would mean everybody has to solve manually in downstream projects.
Right?
On Oct 6, 2014 9:36 PM, "ilkerde" notifications@github.com wrote:

We could introduce the concept of a group acting as constraint boundary.
In plain old english: other group, other constraints. On FS level, we could
easily scope this using folder. The actual purpose of the group could be
to reflect differing constraints for different framework versions (or
platforms, or maybe even environments). Does this makes sense a little?

—
Reply to this email directly or view it on GitHub
#220 (comment).