NuGet Package Dependency update please?

[JayVDZ]

Any chance of updating the NuGet package dependencies please? The constraints are quite stale now and is starting to cause issues with other packages which require newer dependencies.

[smoothdeveloper]

Guys, dealing with a bunch of packages.config scattered through the repository is a big brake on maintenance of dependencies, along with other issues with bare nuget handling.

I've run analysis to migrate to paket and it reports inconsistent versions / target frameworks for several packages.

We know that this often lead to non reproducible builds (msbuild will erase one version and pull another) and runtime errors.

Paket solves all of this.

Package Flurl.Http.Signed is referenced multiple times in different versions: ["0.7.0"; "0.6.2.2015062601"]. Paket will choose the latest one.
Package Flurl.Signed is referenced multiple times in different versions: ["1.0.10"; "1.0.8"]. Paket will choose the latest one.
Package Newtonsoft.Json is referenced multiple times in different versions: ["8.0.3"; "6.0.4"]. Paket will choose the latest one.
Package SimpleRESTServices is referenced multiple times in different versions: ["1.3.0.1-json6"; "1.3.0.1"]. Paket will choose the latest one.
Package Flurl.Http.Signed is referenced multiple times with different target frameworks : [">= net45"; ">= net452"]. Paket may disregard target framework.
Package Flurl.Signed is referenced multiple times with different target frameworks : [">= net45"; ">= net452"]. Paket may disregard target framework.
Package Marvin.JsonPatch.Signed is referenced multiple times with different target frameworks : [">= net45"; ">= net452"]. Paket may disregard target framework.
Package Newtonsoft.Json is referenced multiple times with different target frameworks : [">= net45"; ">= net40"; ">= net452"]. Paket may disregard target framework.
Package SimpleRESTServices is referenced multiple times with different target frameworks : [">= net4"; ">= net40"]. Paket may disregard target framework.

I can help you setup the migration to paket of this repository and the community would be happy to help you make first steps with using the command line.

I've also noticed that build.cmd fails due to trying to download NuGet.exe, this also is simplified with paket.

Please check http://fsprojects.github.io/Paket/ and please let me know if you want me to migrate (keeping same dependencies versions), and then upgrade dependencies in a pain free way, I can make 2 PRs.

Cheers.

[carolynvs]

@Amethi Yeah sorry about that... I added an upper bound to all dependencies when a breaking change was introduced by one package causing new installs to all fail (Thanks to VS/NuGet's new option to install the highest possible dependencies) and that probably wasn't the right decision in retrospect.

@smoothdeveloper I :heart: Paket and am using it very happily for Rackspace.NET and would love help getting OpenStack.NET using it as well. Send me a PR and I will definitely merge it.

I know that Paket can handle dependency ranges in a much more intelligent way. I would appreciate your thoughts on whether we should only have a lower version boundary (e.g. >= 4.1.0) or if it would be helpful to allow a range up to the next major (e.g. >= 4.1.0 && < 5.0.0). That assumes that dependencies are following semver and may just be delaying the problem down the road a bit.

Thank you for starting this conversation and I would really appreciate your input on how best to resolve it!

[JayVDZ]

Yay, thank-you both. Looking forward to that PR @smoothdeveloper!

[smoothdeveloper]

@Amethi & @carolynvs, I've been doing the ground work, I still have issue with building the documentation I assume due to some special version of SHFB, and the set of various versions of same libraries (but we can handle that fine with Paket groups).

Also I wasn't able to run the integration tests, unit tests are running fine.

I think I should actually push that to a branch and seek cooperation from people who actually maintain this project (I'm just passing nearby when I saw potential pain with packages.config), I'll update this thread.

Sorry for not seeing this before!

[smoothdeveloper]

@carolynvs thanks for feedback, regarding nuget package authoring (which I think is the aim of your remark about version ranges), I'm not much experienced with nuget nor paket. We should figure out the "dependency manager" use case first, and then later maybe we can figure out how to make it easier to specify the paket.template files used to author nuget packages for openstack.net itself.

Does that make sense?

[smoothdeveloper]

Also for version bounds and publishing on nuget.org, if users are experiencing pain due to lack of binding redirect, there is not much to do besides recommending them to use paket (which writes those redirects for you) or having them to check that necessary redirects are there if they don't plan to use the same versions of dependencies as openstack.net sdk uses.

Depending how you want to deal with this (either "conservative", the library depends on / supports lowest version possible, or "uptodate" approach in which case openstack.net publishes frequently new nuget with most up to date dependencies). In both cases handling dependencies with paket seems like it will ease the process.

[smoothdeveloper]

@carolynvs I've opened a PR #618 to share the work so far, let me know if you want access to my fork, that might simplify our workflow to complete this migration.

Please let me know which part you'd like me to help with, I'm kind of stuck with integration tests and documentation but will happily give another look if you find any issue.

[carolynvs]

👍 I can help out with the remaining items, and submit them back to your fork.

[carolynvs]

OpenStack.NET v1.7.0 is available on nuget, allowing json.net 6-8. In addition, #618 has been merged into develop, moving us to paket.

That fixes the pain short term and sets us up for managing dependencies better in the future.

For now I will keep the upper/lower bounds on dependencies in the NuGet package definition. With Paket it is now easy to update a dependency and rerelease because the config is centralized.

I am closing this out as I believe the core problem has been addressed and there aren't any further changes needed at this time. Please leave a comment here if there is more that needs to happen.

Thanks!