Pinning package without updating other packages

General Usage
1

Hi,

I’m building off of someone else’s project, so I use their Manifest and Project files. I want to pin the dependencies to prevent it from breaking in the future. However, when I use the pin command, it installs and updates various other packages/dependencies that aren’t specifically listed in the Project.toml, but are in the Manifest.toml, which results in the code breaking. Is this behavior supposed to happen, and is there a way to prevent the other packages from updating?

I’m using Julia 1.4.0 (2020-03-21). An example of what is happening is below:

pkg> pin DifferentialEquations
  Installed SIMDPirates ─────── v0.8.21
  Installed VectorizationBase ─ v0.12.29
  Installed Roots ───────────── v1.0.4
  Installed JuliaVariables ──── v0.2.1
  Installed Ipopt ───────────── v0.6.3
  Installed DiffEqBase ──────── v6.41.1
  Installed OrdinaryDiffEq ──── v5.42.0
  Installed Tables ──────────── v1.0.5
  Installed LoopVectorization ─ v0.8.20
   Updating `~/Path/Project.toml`
  [0c46a032] ~ DifferentialEquations v6.12.0 ⇒ v6.12.0 ⚲
   Updating `~/Path/Manifest.toml`
  [ae81ac8f] + ASL_jll v0.1.1+3
  [c3fe647b] + AbstractAlgebra v0.9.2
  [1520ce14] ↑ AbstractTrees v0.3.2 ⇒ v0.3.3
  [79e6a3ab] ↑ Adapt v1.0.1 ⇒ v2.0.2
  [4fba245c] ↑ ArrayInterface v2.6.1 ⇒ v2.11.0

…continues to update a whole set of other packages.

Thanks!

2

pin should not hit the resolver at all, so this seems like a bug. I can not reproduce it though. If you can find a way to make this happen again it would be great if you could open an issue: https://github.com/JuliaLang/Pkg.jl/issues/new

1 Like
3

Thanks for the insight. I’ve worked on reproducing the issue and got the same results on a Linux machine running Julia 1.4.2. Before I open an issue on GitHub, could it be a setting that is enabled in the repository I’m cloning?

To reproduce:

  1. Clone: https://github.com/RoboticExplorationLab/TortoiseSat.jl
  2. cd to directory
  3. In Julia REPL, ] activate .
  4. pin <package>

Another thing to note is that I get similar behavior when I add a package as it seems to update a lot more packages than necessary (beyond the dependencies). It seems that whenever I use a package related command, it decides to update everything, so I hope it might be an issue with the cloned repository rather than a broader Julia issue.

4

Thanks. Looks like the reason I could not reproduce it is that the manifest file in that repo is inconsistent:

$ pkg resolve
ResolverError: Unsatisfiable requirements detected for package MeshCatMechanisms [6ad125db]:
 MeshCatMechanisms [6ad125db] log:
 ├─possible versions are: [0.0.1-0.0.6, 0.1.0-0.1.1, 0.2.0-0.2.1, 0.3.0, 0.4.0, 0.5.0, 0.6.0, 0.7.0-0.7.1] or uninstalled
 ├─restricted to versions 0.5.0 by an explicit requirement, leaving only versions 0.5.0
 └─restricted by compatibility requirements with MeshCat [283c5d60] to versions: 0.7.0-0.7.1 or uninstalled — no versions left
   └─MeshCat [283c5d60] log:
     ├─possible versions are: [0.1.0-0.1.2, 0.2.0-0.2.3, 0.3.0, 0.4.0, 0.5.0, 0.6.0, 0.7.0, 0.8.0, 0.9.0-0.9.1, 0.10.0, 0.11.0-0.11.2] or uninstalled
     └─restricted to versions 0.10.0 by an explicit requirement, leaving only versions 0.10.0

so Pkg kinda has to re-resolve here which results in those updates.

3 Likes
5

Sorry for hijacking the thread, but I happen to have encountered just this week a similar situation, where a Manifest would be inconsistent and impossible to instantiate for this reason. Would you have any idea about possible causes for such inconsistencies (apart from someone manually tampering with the manifest)?

Could a change in the version of Julia cause such inconsistencies? Or compat bounds that would have been changed retroactively in the registry?

6

I think it can only happen if you tamper with it manually. In particular, neither Julia version or changes in the registry should have any impact on instantiate failing.

2 Likes
7

Not even if compat bounds are retroactively “capped” in the registry using a tool such as RetroCap.jl? That was my most plausible explanation so far…

Thanks for your answer anyway!

8

Not if you have a manifest file – that is kind of the point of the manifest that you don’t have to resolve and look at anything else like the registry etc.

1 Like
9

Ah, so Pkg.instantiate() “blindly” instantiates all dependencies at the specified version, without even looking at their compat bounds (which was the resolver’s job). That makes sense, thanks!