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

Vidarls · 2014-10-24T07:14:26Z

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?

The text was updated successfully, but these errors were encountered:

Vidarls · 2014-10-24T07:18:02Z

Got it working this way:

Add the package manually to paket.references for the project
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 · 2014-10-24T07:22:25Z

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:

Add the package manually to paket.references for the project

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
#295 (comment).

agross · 2014-10-24T10:27:21Z

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 · 2014-10-24T10:34:33Z

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
#295 (comment).

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
#295 (comment).

agross · 2014-10-24T10:43:18Z

OK, do it then ;-)

Vidarls · 2014-10-24T10:43:21Z

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 · 2014-10-24T10:49:05Z

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

forki · 2014-10-24T10:59:01Z

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 · 2014-10-24T11:11:07Z

:) 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 · 2014-10-24T12:03:53Z

could you please try 0.10.0-alpha002

Vidarls · 2014-10-24T13:20:39Z

Ok, some weird stuff happened

Setup pre test:

1 test project with :

Autofixture.Xunit
Xunit.Extensions

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

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.
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
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 · 2014-10-24T13:39:17Z

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)

XUnit is dependency of xunit.extensions, right?
you have xunit and xunit.extensions in references file?
it removes xunit and keeps xunit.extensions.

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 · 2014-10-24T13:42:07Z

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

Vidarls · 2014-10-24T13:49:30Z

@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 · 2014-10-24T13:51:32Z

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 · 2014-10-24T13:57:52Z

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,

add reference to a reference file => paket update
remove reference from a reference file => paket update

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 · 2014-10-24T14:00:03Z

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 · 2014-10-24T14:02:15Z

@forki Still, what I don't like about the paket update that's required after editing paket.dependencies (as outlined by @Vidarls #295 (comment)) is that it will update all dependencies, not just the one I added.

forki · 2014-10-24T14:04:08Z

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

agross · 2014-10-24T14:08:10Z

@forki Alright. I knew I missed something.

forki · 2014-10-24T14:11:40Z

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

Vidarls · 2014-10-24T14:14:05Z

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 · 2014-10-24T14:15:52Z

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
#295 (comment).

isaacabraham · 2014-10-24T17:19:09Z

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 #295 (comment) . https://github.com/notifications/beacon/ABswNc45XO9GIPfa6iC_c3hVxfl-3ejVks5nGk6wgaJpZM4Cyh4c.gif

forki · 2014-10-24T17:25:27Z

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

forki added the enhancement label Oct 24, 2014

forki added a commit that referenced this issue Oct 24, 2014

Make add and remove idempotent - referencing #295, #279

0436f85

forki closed this as completed in 81317a2 Oct 26, 2014

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

Vidarls commented Oct 24, 2014

Vidarls commented Oct 24, 2014

forki commented Oct 24, 2014

agross commented Oct 24, 2014

forki commented Oct 24, 2014

agross commented Oct 24, 2014

Vidarls commented Oct 24, 2014

Vidarls commented Oct 24, 2014

forki commented Oct 24, 2014

Vidarls commented Oct 24, 2014

forki commented Oct 24, 2014

Vidarls commented Oct 24, 2014

forki commented Oct 24, 2014

forki commented Oct 24, 2014

Vidarls commented Oct 24, 2014

forki commented Oct 24, 2014

Vidarls commented Oct 24, 2014

forki commented Oct 24, 2014

agross commented Oct 24, 2014

forki commented Oct 24, 2014

agross commented Oct 24, 2014

forki commented Oct 24, 2014

Vidarls commented Oct 24, 2014

forki commented Oct 24, 2014

isaacabraham commented Oct 24, 2014

forki commented Oct 24, 2014

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

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

Comments

Vidarls commented Oct 24, 2014

Vidarls commented Oct 24, 2014

forki commented Oct 24, 2014

agross commented Oct 24, 2014

forki commented Oct 24, 2014

agross commented Oct 24, 2014

Vidarls commented Oct 24, 2014

Vidarls commented Oct 24, 2014

forki commented Oct 24, 2014

Vidarls commented Oct 24, 2014

forki commented Oct 24, 2014

Vidarls commented Oct 24, 2014

forki commented Oct 24, 2014

forki commented Oct 24, 2014

Vidarls commented Oct 24, 2014

forki commented Oct 24, 2014

Vidarls commented Oct 24, 2014

forki commented Oct 24, 2014

agross commented Oct 24, 2014

forki commented Oct 24, 2014

agross commented Oct 24, 2014

forki commented Oct 24, 2014

Vidarls commented Oct 24, 2014

forki commented Oct 24, 2014

isaacabraham commented Oct 24, 2014

forki commented Oct 24, 2014