New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to remove dangling dependency #1596

Closed
theimowski opened this Issue Apr 12, 2016 · 5 comments

Comments

Projects
None yet
2 participants
@theimowski
Member

theimowski commented Apr 12, 2016

Description

Unable to remove dangling dependency - NuGet.CommandLine is defined in paket.dependencies, but not used by any paket.references

Repro steps

  1. checkout theimowski/suave@8dd7d74
  2. run paket.exe -v remove nuget NuGet.CommandLine group Build

Expected behavior

NuGet.CommandLine should be removed from paket.dependencies

Actual behavior

C:\github\suave (merge_nupkgs)
λ tools\paket.exe -v remove nuget NuGet.CommandLine group Build
Paket version 2.58.14.0
found: C:\github\suave\paket.dependencies
Paket failed with:
        The given key was not present in the dictionary.
StackTrace:
     at Microsoft.FSharp.Collections.MapTreeModule.find[TValue,a](IComparer`1 comparer, TValue k, MapTree`2 m)
   at Paket.ProjectFileModule.hasPackageInstalled(GroupName groupName, PackageName package, ProjectFile project)
   at Paket.RemoveProcess.removeFromProjects@73(PackageName packageName, Boolean interactive, GroupName groupName, IEnumerable`1 projects)
   at Paket.RemoveProcess.Remove@79-8.Invoke(ProjectFile[] arg00)
   at Paket.RemoveProcess.remove(FSharpFunc`2 removeFromProjects, String dependenciesFileName, GroupName groupName, PackageName package, Boolean force, Boolean hard, Boolean installAfter)
   at <StartupCode$Paket-Core>.$PublicAPI.Remove@433-9.Invoke(Unit unitVar0)
   at Paket.Utils.RunInLockedAccessMode[a](String rootFolder, FSharpFunc`2 action)
   at Paket.Program.handler@342-13.Invoke(ParseResults`1 results)
   at Paket.Program.processWithValidation[T](FSharpFunc`2 validateF, FSharpFunc`2 commandF, Command command, String[] args)
   at Paket.Program.processCommand@61-1.Invoke(Command command, String[] args)
   at Paket.Program.main()

Known workarounds

One can remove the dependency from paket.dependencies manually - however I'm not sure, what command should I invoke afterwards to update paket.lock, so that other dependencies are not modified?

theimowski added a commit to theimowski/suave that referenced this issue Apr 12, 2016

@forki forki closed this in 34c9217 Apr 12, 2016

@forki forki added the bug label Apr 12, 2016

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Apr 12, 2016

Member

Bug is fixed.

One can remove the dependency from paket.dependencies manually - however I'm not sure, what command should I invoke afterwards to update paket.lock, so that other dependencies are not modified?

"paket install"

Member

forki commented Apr 12, 2016

Bug is fixed.

One can remove the dependency from paket.dependencies manually - however I'm not sure, what command should I invoke afterwards to update paket.lock, so that other dependencies are not modified?

"paket install"

@theimowski

This comment has been minimized.

Show comment
Hide comment
@theimowski

theimowski Apr 12, 2016

Member

Thanks. With Paket 2.59.0 this is result of running paket remove nuget NuGet.CommandLine group Build: theimowski/suave@6cadb6d - is this desired behavior that dependencies have been updated?

Member

theimowski commented Apr 12, 2016

Thanks. With Paket 2.59.0 this is result of running paket remove nuget NuGet.CommandLine group Build: theimowski/suave@6cadb6d - is this desired behavior that dependencies have been updated?

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Apr 12, 2016

Member

yes it's running install and is detecting a change. maybe we should restrict install to the touched group

Member

forki commented Apr 12, 2016

yes it's running install and is detecting a change. maybe we should restrict install to the touched group

@theimowski

This comment has been minimized.

Show comment
Hide comment
@theimowski

theimowski Apr 12, 2016

Member

ok my fault - I've missed the --no-install switch. Re restricting install to the group only - probably a minor "nice to have". However there's one thing, which could deserve its own issue: the dependency was the only one in this group - after running the command, group got orphaned (see here)

Member

theimowski commented Apr 12, 2016

ok my fault - I've missed the --no-install switch. Re restricting install to the group only - probably a minor "nice to have". However there's one thing, which could deserve its own issue: the dependency was the only one in this group - after running the command, group got orphaned (see here)

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Apr 12, 2016

Member

yes please create 2 new issues ;-)

Member

forki commented Apr 12, 2016

yes please create 2 new issues ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment