search

fsprojects / Paket

A dependency manager for .NET with support for NuGet packages and Git repositories.
https://fsprojects.github.io/Paket/
MIT License
2.02k stars 525 forks source link

Adding an existing package to new project added to solution #295

Closed Vidarls closed 10 years ago

Vidarls commented 10 years ago

Case: I added a new test project to my solution. I previously had another test project using Xunit, and as such I wanted to add Xunit to the new test project.

Any call to paket add fails because Xunit is already in paket.dependencies. Tried both --hard and --force.

Is this not yet supported, or am I doing it wrong?

Vidarls commented 10 years ago

Got it working this way:

  1. Add the package manually to paket.references for the project
  2. Running paket install

Suggestion: extend Paket add to do this automatically if you run paket add nuget [package] --interactive and the package is already in the paket.dependencies file.

forki commented 10 years ago

Yes adding new projects is an open issue. @agross would you prefer to extend paket add as described above or a different command? On Oct 24, 2014 9:18 AM, "Vidar Løvbrekke Sømme" notifications@github.com wrote:

Got it working this way:

  1. Add the package manually to paket.references for the project
  2. Running paket install

Suggestion: extend Paket add to do this automatically if you run paket add nuget [package] --interactive and the package is already in the paket.dependencies file.

— Reply to this email directly or view it on GitHub https://github.com/fsprojects/Paket/issues/295#issuecomment-60352601.

agross commented 10 years ago

Hm, not really sure I like the paket add idea. I'd use @Vidarls suggested method.

From my point of view, add is supposed to add a new solution-level dependency. But if users like @Vidarls intend to use it for adding new project-level deps we should support it. For the project-level case, we should not update the lockfile, even if there are newer versions available.

forki commented 10 years ago

Actually I like to use the add command for this. The new remove command will look like a dual then. I like that. On Oct 24, 2014 12:27 PM, "Alexander Groß" notifications@github.com wrote:

Hm, not really sure I like the paket add idea. I'd use @Vidarls https://github.com/Vidarls suggested method https://github.com/fsprojects/Paket/issues/295#issuecomment-60352601.

From my point of view, add is supposed to add a new solution-level dependency. But if users like @Vidarls https://github.com/Vidarls intend to use it for adding new project-level deps we should support it. For the project-level case, we should not update the lockfile, even if there are newer versions available.

— Reply to this email directly or view it on GitHub https://github.com/fsprojects/Paket/issues/295#issuecomment-60370121.

agross commented 10 years ago

OK, do it then ;-)

Vidarls commented 10 years ago

There need to be some support if the topology of the solution changes. Or if you remove a package from one project and want to re-add it.

In my opinion, relying on manually creating files is not giving users a good experience, there should be some command to do this.

Vidarls commented 10 years ago

Sorry, didn't see that the discussion was settled before I posted previous comment..

forki commented 10 years ago

I think Alex's point is: we need no tooling. references files are sooo easy to edit.

But we will do it. I think it makes sense to have both options. Also for automation on top.

Vidarls commented 10 years ago

:) Doesn't get easier than names in a text file, but as a relatively new user I first tried all sorts of combinations with add before I as a sort of blind shot tried adding the reference file and doing paket install.

Meaning it was not very intuitive to get from "I want to do X" to "I achieved X".

Point being, tooling and user experience are important if there are any ambition to actually get some level of adoption. (Particularly when the alternative is nuget, which is really good at the tooling bit).

But let us not keep beating this particular horse, discussion has long been settled. I just wanted to share my thoughts as someone who as relatively recently adopted Paket, to give my perspective on the user experience.

forki commented 10 years ago

could you please try 0.10.0-alpha002

Vidarls commented 10 years ago

Ok, some weird stuff happened

Setup pre test:

1 test project with :

in the reference file

In the paket.dependencies file, xunit.extensions is listed with no version constraints, Autofixture.Xunit is listed with the version constraint !~> 3 indicating the pessimistic nuget type resolve of indirect dependencies.

Tests

  1. Paket add nuget Xunit --interactive This bypassed the indirect version constraint on Autofixture and gave me the latest version of both Xunit and Xunit.Extensions. I answered No on all the questions to add to any project. Doing a subsequent paket update reverted to the correct versions.
  2. Did one more Paket add nuget Xunit --interactive Now I answered yes to add to a second test project. Once more I got the wrong version (ignoring constraint from Autofixture) and for some reason both Xunit and Xunit.Extensions was added as references to the new project. Again paket update fixed the version
  3. Paket remove nuget Xunit --interactive answering yes to remove from the new project. Again the version was updated to the wrong version on both Xunit.Extensions and Xunit. Only Xunit was removed from the project, Xunit.Extensions still being listed as a reference (and in the paket.references file).

(I am slowly warming to @agross simple text editing solution. Actually a alot less work than doing paket add / remove. Only problem is to make it discoverable for new users.)

forki commented 10 years ago

I think I understand what's happening.

Problem 1) - The "selective update" after add has to keep the requirements of Xunit. I think I can fix this

Problem 2)

I think this is a bit tricky. a) in interactive mode we could ask if you want to remove xunit.extensions. b) in standard mode we should fail

what do you think?

forki commented 10 years ago

@isaacabraham is this the same behaviour you reported last time on twitter?

Vidarls commented 10 years ago

@forki I think the main problem during removal is the involuntary update of the version.

The really strange thing is that Xunit and xunit.extensions was added to the project even though I only did paket add nuget Xunit --interactive

Once this happened, the project had both Xunit and Xunit.extensions in the reference file, and thus removing only xunit is basically what paket simplify would do.

forki commented 10 years ago

I think the main problem during removal is the involuntary update of the version.

yes that's bad. But we can't just remove it from the lockfile since it could be an indirect dependency. We still need to resolve.

Vidarls commented 10 years ago

The weird thing is that I find the file-based workflow to be really low friction, now that I've discovered it. The only thing I'm missing is the autocomplete from nuget. I think the biggest obstacle is to have users discover it, (though I think the fact that paket adds the files to the project helps a lot in discoverability.

It is slightly more time consuming than my normal nuget workflow due to the diligence paid to versioning (that nuget basically screws up in situations like my test above). But other than that it is really nice. (//cc @agross )

So since the file based thingy is working fine, IE,

Seems to yield no suprices.

Could we be missing some potential approach that way?

IE, if the packate is already in the paket.dependency fil, just add to to the projects reference file and run paket update. Else, add the package to the paket.dependency file and the project reference file => paket update

forki commented 10 years ago

I just tried to reproduce: 

source https://nuget.org/api/v2

nuget Autofixture.Xunit !~> 3
nuget Xunit.Extensions

paket update gives:

NUGET
  remote: https://nuget.org/api/v2
  specs:
    AutoFixture (3.21.0)
    AutoFixture.Xunit (3.21.0)
      AutoFixture (>= 3.21.0)
      xunit.extensions (>= 1.8.0.1549)
    xunit (1.9.2)
    xunit.extensions (1.9.2)
      xunit (1.9.2)

after paket add nuget xunit:

NUGET
  remote: https://nuget.org/api/v2
  specs:
    AutoFixture (3.21.0)
    AutoFixture.Xunit (3.21.0)
      AutoFixture (>= 3.21.0)
      xunit.extensions (>= 1.8.0.1549)
    xunit (1.9.2)
    xunit.extensions (1.9.2)
      xunit (1.9.2)

so the same thing. It doesn't change the lockfile.

agross commented 10 years ago

@forki Still, what I don't like about the paket update that's required after editing paket.dependencies (as outlined by @Vidarls https://github.com/fsprojects/Paket/issues/295#issuecomment-60390003) is that it will update all dependencies, not just the one I added.

forki commented 10 years ago

@agross see http://fsprojects.github.io/Paket/paket-update.html#Updating-a-single-package

agross commented 10 years ago

@forki Alright. I knew I missed something.

forki commented 10 years ago

so it seems I'm back to "can't reproduce". Damn it. I hoped to release this today ;-)

Vidarls commented 10 years ago

Did a new test

Paket dependencies before test: 

source https://nuget.org/api/v2

nuget FSharp.Formatting
nuget Nuget.CommandLine
nuget FAKE
nuget SourceLink.Fake
nuget Paket.Core
nuget NGitlab ~> 1.0
nuget Xunit.runners
nuget Xunit.Extensions
nuget Autofixture.Xunit !~> 3

github fsharp/FAKE modules/Octokit/Octokit.fsx

Lock file pre test:

NUGET
  remote: https://nuget.org/api/v2
  specs:
    AutoFixture (3.21.0)
    AutoFixture.Xunit (3.21.0)
      AutoFixture (>= 3.21.0)
      xunit.extensions (>= 1.8.0.1549)
    FAKE (3.7.5)
    FSharp.Compiler.Service (0.0.67)
    FSharp.Formatting (2.4.36)
      FSharp.Compiler.Service (0.0.67)
      Microsoft.AspNet.Razor (2.0.30506.0)
      RazorEngine (3.3.0)
    Microsoft.AspNet.Razor (2.0.30506.0)
    Microsoft.Net.Http (2.0.20505.0)
    MySql.Data (5.1.7.0)
    NetMQ (3.3.0.10)
    Newtonsoft.Json (6.0.4)
    NGitLab (1.0.1.0)
    NuGet.CommandLine (2.8.3)
    Octokit (0.5.2)
      Microsoft.Net.Http (>= 0)
    Paket.Core (0.5.6)
    RazorEngine (3.3.0)
      Microsoft.AspNet.Razor (>= 2.0.30506.0)
    Simple.Data.Ado (0.19.0.0)
      Simple.Data.Core (>= 0.19.0.0)
    Simple.Data.Core (0.19.0.0)
    Simple.Data.Mysql (0.19.0.5)
      Simple.Data.Ado (>= 0.19.0.0)
    SourceLink.Fake (0.4.0)
    xunit (1.8.0.1549)
    xunit.extensions (1.8.0.1549)
      xunit (>= 1.8.0.1549)
    xunit.runners (1.9.2)

GITHUB
  remote: fsharp/FAKE
  specs:
    modules/Octokit/Octokit.fsx (19c283610f464ca5a82e01056f0e84c1f1c82550)
      Octokit (>= 0)

Dependencies file post test:

source https://nuget.org/api/v2

nuget FSharp.Formatting
nuget Nuget.CommandLine
nuget FAKE
nuget SourceLink.Fake
nuget Paket.Core
nuget NGitlab ~> 1.0
nuget Xunit.runners
nuget Xunit.Extensions
nuget Autofixture.Xunit !~> 3
nuget Xunit

github fsharp/FAKE modules/Octokit/Octokit.fsx

Lock file post test:

NUGET
  remote: https://nuget.org/api/v2
  specs:
    AutoFixture (3.21.0)
    AutoFixture.Xunit (3.21.0)
      AutoFixture (>= 3.21.0)
      xunit.extensions (>= 1.8.0.1549)
    FAKE (3.7.5)
    FSharp.Compiler.Service (0.0.67)
    FSharp.Formatting (2.4.36)
      FSharp.Compiler.Service (0.0.67)
      Microsoft.AspNet.Razor (2.0.30506.0)
      RazorEngine (3.3.0)
    Microsoft.AspNet.Razor (2.0.30506.0)
    Microsoft.Net.Http (2.0.20505.0)
    MySql.Data (5.1.7.0)
    NetMQ (3.3.0.10)
    Newtonsoft.Json (6.0.4)
    NGitLab (1.0.1.0)
    NuGet.CommandLine (2.8.3)
    Octokit (0.5.2)
      Microsoft.Net.Http (>= 0)
    Paket.Core (0.5.6)
    RazorEngine (3.3.0)
      Microsoft.AspNet.Razor (>= 2.0.30506.0)
    Simple.Data.Ado (0.19.0.0)
      Simple.Data.Core (>= 0.19.0.0)
    Simple.Data.Core (0.19.0.0)
    Simple.Data.Mysql (0.19.0.5)
      Simple.Data.Ado (>= 0.19.0.0)
    SourceLink.Fake (0.4.0)
    xunit (1.9.2)
    xunit.extensions (1.8.0.1549)
      xunit (>= 1.8.0.1549)
    xunit.runners (1.9.2)
GITHUB
  remote: fsharp/FAKE
  specs:
    modules/Octokit/Octokit.fsx (19c283610f464ca5a82e01056f0e84c1f1c82550)
      Octokit (>= 0)

(Yes I know there seems to be no reason for Mysql and NetMQ, but not all can be posted on the internets..)

All my Xunit references was updated to 1.9.2

After subsequent run of paket update : 

NUGET
  remote: https://nuget.org/api/v2
  specs:
    AutoFixture (3.21.0)
    AutoFixture.Xunit (3.21.0)
      AutoFixture (>= 3.21.0)
      xunit.extensions (>= 1.8.0.1549)
    FAKE (3.7.5)
    FSharp.Compiler.Service (0.0.67)
    FSharp.Formatting (2.4.36)
      FSharp.Compiler.Service (0.0.67)
      Microsoft.AspNet.Razor (2.0.30506.0)
      RazorEngine (3.3.0)
    Microsoft.AspNet.Razor (2.0.30506.0)
    Microsoft.Bcl (1.1.9)
      Microsoft.Bcl.Build (>= 1.0.14)
    Microsoft.Bcl.Build (1.0.21)
    Microsoft.Net.Http (2.2.28)
      Microsoft.Bcl (>= 1.1.9)
      Microsoft.Bcl.Build (>= 1.0.14)
    MySql.Data (5.1.7.0)
    NetMQ (3.3.0.10)
    Newtonsoft.Json (6.0.4)
    NGitLab (1.0.1.0)
    NuGet.CommandLine (2.8.3)
    Octokit (0.5.2)
      Microsoft.Net.Http (>= 0)
    Paket.Core (0.5.6)
    RazorEngine (3.3.0)
      Microsoft.AspNet.Razor (>= 2.0.30506.0)
    Simple.Data.Ado (0.19.0.0)
      Simple.Data.Core (>= 0.19.0.0)
    Simple.Data.Core (0.19.0.0)
    Simple.Data.Mysql (0.19.0.5)
      Simple.Data.Ado (>= 0.19.0.0)
    SourceLink.Fake (0.4.0)
    xunit (1.8.0.1549)
    xunit.extensions (1.8.0.1549)
      xunit (>= 1.8.0.1549)
    xunit.runners (1.9.2)

GITHUB
  remote: fsharp/FAKE
  specs:
    modules/Octokit/Octokit.fsx (19c283610f464ca5a82e01056f0e84c1f1c82550)
      Octokit (>= 0)

All is well again.

forki commented 10 years ago

Ok thanks. Now I know where I have to look. That's very good feedback. On Oct 24, 2014 4:14 PM, "Vidar Løvbrekke Sømme" notifications@github.com wrote:

Did a new test

Paket dependencies before test:

source https://nuget.org/api/v2

nuget FSharp.Formatting nuget Nuget.CommandLine nuget FAKE nuget SourceLink.Fake nuget Paket.Core nuget NGitlab ~> 1.0 nuget Xunit.runners nuget Xunit.Extensions nuget Autofixture.Xunit !~> 3

github fsharp/FAKE modules/Octokit/Octokit.fsx

Lock file pre test:

NUGET remote: https://nuget.org/api/v2 specs: AutoFixture (3.21.0) AutoFixture.Xunit (3.21.0) AutoFixture (>= 3.21.0) xunit.extensions (>= 1.8.0.1549) FAKE (3.7.5) FSharp.Compiler.Service (0.0.67) FSharp.Formatting (2.4.36) FSharp.Compiler.Service (0.0.67) Microsoft.AspNet.Razor (2.0.30506.0) RazorEngine (3.3.0) Microsoft.AspNet.Razor (2.0.30506.0) Microsoft.Net.Http (2.0.20505.0) MySql.Data (5.1.7.0) NetMQ (3.3.0.10) Newtonsoft.Json (6.0.4) NGitLab (1.0.1.0) NuGet.CommandLine (2.8.3) Octokit (0.5.2) Microsoft.Net.Http (>= 0) Paket.Core (0.5.6) RazorEngine (3.3.0) Microsoft.AspNet.Razor (>= 2.0.30506.0) Simple.Data.Ado (0.19.0.0) Simple.Data.Core (>= 0.19.0.0) Simple.Data.Core (0.19.0.0) Simple.Data.Mysql (0.19.0.5) Simple.Data.Ado (>= 0.19.0.0) SourceLink.Fake (0.4.0) xunit (1.8.0.1549) xunit.extensions (1.8.0.1549) xunit (>= 1.8.0.1549) xunit.runners (1.9.2)

GITHUB remote: fsharp/FAKE specs: modules/Octokit/Octokit.fsx (19c283610f464ca5a82e01056f0e84c1f1c82550) Octokit (>= 0)

Dependencies file post test:

source https://nuget.org/api/v2 source http://10.101.1.61:8081/nuget/dev

nuget FSharp.Formatting nuget Nuget.CommandLine nuget FAKE nuget SourceLink.Fake nuget Paket.Core nuget NGitlab ~> 1.0 nuget Xunit.runners nuget Xunit.Extensions nuget Autofixture.Xunit !~> 3 nuget Xunit

github fsharp/FAKE modules/Octokit/Octokit.fsx

Lock file post test:

NUGET remote: https://nuget.org/api/v2 specs: AutoFixture (3.21.0) AutoFixture.Xunit (3.21.0) AutoFixture (>= 3.21.0) xunit.extensions (>= 1.8.0.1549) FAKE (3.7.5) FSharp.Compiler.Service (0.0.67) FSharp.Formatting (2.4.36) FSharp.Compiler.Service (0.0.67) Microsoft.AspNet.Razor (2.0.30506.0) RazorEngine (3.3.0) Microsoft.AspNet.Razor (2.0.30506.0) Microsoft.Net.Http (2.0.20505.0) MySql.Data (5.1.7.0) NetMQ (3.3.0.10) Newtonsoft.Json (6.0.4) NGitLab (1.0.1.0) NuGet.CommandLine (2.8.3) Octokit (0.5.2) Microsoft.Net.Http (>= 0) Paket.Core (0.5.6) RazorEngine (3.3.0) Microsoft.AspNet.Razor (>= 2.0.30506.0) Simple.Data.Ado (0.19.0.0) Simple.Data.Core (>= 0.19.0.0) Simple.Data.Core (0.19.0.0) Simple.Data.Mysql (0.19.0.5) Simple.Data.Ado (>= 0.19.0.0) SourceLink.Fake (0.4.0) xunit (1.9.2) xunit.extensions (1.8.0.1549) xunit (>= 1.8.0.1549) xunit.runners (1.9.2) GITHUB remote: fsharp/FAKE specs: modules/Octokit/Octokit.fsx (19c283610f464ca5a82e01056f0e84c1f1c82550) Octokit (>= 0)

(Yes I know there seems to be no reason for Mysql and NetMQ, but not all can be posted on the internets..)

All my Xunit references was updated to 1.9.2

After subsequent run of paket update :

NUGET remote: https://nuget.org/api/v2 specs: AutoFixture (3.21.0) AutoFixture.Xunit (3.21.0) AutoFixture (>= 3.21.0) xunit.extensions (>= 1.8.0.1549) FAKE (3.7.5) FSharp.Compiler.Service (0.0.67) FSharp.Formatting (2.4.36) FSharp.Compiler.Service (0.0.67) Microsoft.AspNet.Razor (2.0.30506.0) RazorEngine (3.3.0) Microsoft.AspNet.Razor (2.0.30506.0) Microsoft.Bcl (1.1.9) Microsoft.Bcl.Build (>= 1.0.14) Microsoft.Bcl.Build (1.0.21) Microsoft.Net.Http (2.2.28) Microsoft.Bcl (>= 1.1.9) Microsoft.Bcl.Build (>= 1.0.14) MySql.Data (5.1.7.0) NetMQ (3.3.0.10) Newtonsoft.Json (6.0.4) NGitLab (1.0.1.0) NuGet.CommandLine (2.8.3) Octokit (0.5.2) Microsoft.Net.Http (>= 0) Paket.Core (0.5.6) RazorEngine (3.3.0) Microsoft.AspNet.Razor (>= 2.0.30506.0) Simple.Data.Ado (0.19.0.0) Simple.Data.Core (>= 0.19.0.0) Simple.Data.Core (0.19.0.0) Simple.Data.Mysql (0.19.0.5) Simple.Data.Ado (>= 0.19.0.0) SourceLink.Fake (0.4.0) xunit (1.8.0.1549) xunit.extensions (1.8.0.1549) xunit (>= 1.8.0.1549) xunit.runners (1.9.2)

GITHUB remote: fsharp/FAKE specs: modules/Octokit/Octokit.fsx (19c283610f464ca5a82e01056f0e84c1f1c82550) Octokit (>= 0)

All is well again.

— Reply to this email directly or view it on GitHub https://github.com/fsprojects/Paket/issues/295#issuecomment-60392249.

isaacabraham commented 10 years ago

No, that was doing an Add effectively did an Update of the whole dependency chain.

From: Steffen Forkmann [mailto:notifications@github.com] Sent: 24 October 2014 14:42 To: fsprojects/Paket Cc: Isaac Abraham Subject: Re: [Paket] Adding an existing package to new project added to solution (#295)

@isaacabraham https://github.com/isaacabraham is this the same behaviour you reported last time on twitter?

— Reply to this email directly or view it on GitHub https://github.com/fsprojects/Paket/issues/295#issuecomment-60388046 . https://github.com/notifications/beacon/ABswNc45XO9GIPfa6iC_c3hVxfl-3ejVks5nGk6wgaJpZM4Cyh4c.gif

forki commented 10 years ago

I can reproduce and know what the error is. Will fix next week. thanks