convert-from-nuget silently upgrades mismatched versions

[isaacabraham]

Description

Given two packages.config files as per below, a lock file is generated that silently removes the "lower" version of the dependency.

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="PetaPoco" version="5.1.153" targetFramework="net452" />
</packages>

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="PetaPoco" version="1.9.0" targetFramework="net452" />
</packages>

Output lock file: -

  remote: https://www.nuget.org/api/v2
    PetaPoco (5.1.153)

I'm not sure what the expected behaviour is, but I imagine it's not to lose the 1.9.0 version.

[forki]

Do you have a zip?

[isaacabraham]

test-repro.zip

[isaacabraham]

cc: @theimowski

[isaacabraham]

Note that I'm running by calling Paket functions directly in an F# script. If you run this from the command line, you get the following output: -

"Package PetaPoco is referenced multiple times in different versions: ["5.1.153"; "1.9.0"]. Paket will choose the latest one."

That's good - although is that really what is desired behaviour?

[isaacabraham]

BTW - the command I'm using are: -

    Dependencies.ConvertFromNuget(false, true, false, None, DirectoryInfo nugetPath)
    Dependencies.Locate(nugetPath).Simplify(false)

[forki]

I think it's a sane default, but we probably want to add a "strict" parameter which would add both and then resolver will complain in later phase

[isaacabraham]

Going from 1.9.0 to 5.3.x might well introduce significant breaking changes. Probably the last thing we want is someone to run convert-from-nuget and find that their application doesn't build or (even worse) builds and behaves differently at runtime.

[forki]

true. maybe make "strict" the default and create a new parameter for the current behaviour.

2016-08-11 12:56 GMT+02:00 Isaac Abraham notifications@github.com:

Going from 1.9.0 to 5.3.x might well introduce significant breaking changes. Probably the last thing we want is someone to run convert-from-nuget and find that their application doesn't build or (even worse) builds and behaves differently at runtime.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/fsprojects/Paket/issues/1850#issuecomment-239129911, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNI5IsBetxy6-zCuWJl132fCh5kPdks5qev_SgaJpZM4Jh_-U .

[theimowski]

Yeah that was by design. I'm not sure however whether defaulting to lowest version solves the problem - you might still not compile if you use a feature from the newer version.

[isaacabraham]

@theimowski I think it should by default simply not convert if there's mismatched versions (or put multiple entries in the dependencies file which would then fail). If there's a flag supplied e.g. auto-update, it should do what it currently does.

[theimowski]

Or we could do something like fail convert by default, and add --interactive flag which would prompt (only from command line) for specific version from the various present versions

[forki]

that sounds good as well

2016-08-11 13:55 GMT+02:00 Tomasz Heimowski notifications@github.com:

Or we could do something like fail convert by default, and add --interactive flag which would prompt (only from command line) for specific version from the various present versions

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/fsprojects/Paket/issues/1850#issuecomment-239140423, or mute the thread https://github.com/notifications/unsubscribe-auth/AADgNOQ6nP2t3jl5mcDYqqrxASZMrnKhks5qew2rgaJpZM4Jh_-U .

[isaacabraham]

You might want a "auto upgrade" flag as well though for automated solutions (or if you're using Paket API directly).