Update of copy_local doesn't regenerate lock file
Nobody has claimed this yet.
- Dominant language
- F#
- Stars
- 2.1k
- Forks
- 528
- Avg merge
- 1d 12m
- Merged PRs (30d)
- 54
Description
Description
I have a dependency for which I need to set copy_local: false, it works as expected and also marks all the transitive dependencies the same way. But then I need to reference some of the transitive dependencies directly and, as far as it's resolved with copy_local: false already, I add it and explicitly mark with copy_local: true, but this has no result. Package is still marked as copy_local: false in the resulting lock file, unless I delete file completely and regenerate it from scratch.
Repro steps
- Add dependency with
copy_local: falseto thepaket.dependenciesfile
source https://api.nuget.org/v3/index.json
storage: none
framework: net472
nuget Microsoft.Build copy_local: false
And call paket install
- Add some of the initial package transitive dependencies with
copy_local: true
source https://api.nuget.org/v3/index.json
storage: none
framework: net472
nuget Microsoft.Build copy_local: false
nuget Microsoft.Bcl.AsyncInterfaces copy_local: true
And call paket install
Expected behavior
Microsoft.Bcl.AsyncInterfaces should be resolved with copy_local: true
Actual behavior
Microsoft.Bcl.AsyncInterfaces is still copy_local: false in the lock file
Known workarounds
Delete lock file, call paket install again.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the issue by editing paket.dependencies and running paket install with the two copy_local settings shown, then inspect the generated lock file. Done means changing a transitive dependency to copy_local: true updates its lock-file entry without deleting the lock file first.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- fsharp
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 42/100