How does Pkg determine the version of a package?

General Usage
1

I am confused by the behaviour of Pkg3. It seems that the version field in the Project.toml is ignored and instead the registries determines the latest available version. I would have expected that the local Project.toml of a deved package always has priority.

Here is an example, maybe I instead something wrong:

(v1.0) pkg> generate Bar
Generating project Bar:
    Bar/Project.toml
    Bar/src/Bar.jl

(v1.0) pkg> dev ./Bar
 Resolving package versions...
  Updating `~/.julia/environments/v1.0/Project.toml`
  [5a72affa] + Bar v0.1.0 [`~/.julia/environments/v1.0/../../dev/Bar`]
  Updating `~/.julia/environments/v1.0/Manifest.toml`
  [5a72affa] + Bar v0.1.0 [`~/.julia/environments/v1.0/../../dev/Bar`]

Now I change the generated Project.toml and set version = "0.2.0". Going back to Julia:

(v1.0) pkg> resolve
  Updating registry at `~/.julia/registries/General`
  Updating git-repo `https://github.com/JuliaRegistries/General.git`
 Resolving package versions...
ERROR: Unsatisfiable requirements detected for package Bar [5a72affa]:
 Bar [5a72affa] log:
 ├─possible versions are: 0.2.0 or uninstalled
 ├─Bar [5a72affa] is fixed to version 0.2.0
 └─restricted to versions 0.1.0 by an explicit requirement — no versions left

I would have expected that Pkg would just recognize that Bar is now at version 0.2.0.

I run into concrete problems when I wanted to upgrade a dependency (minor version jump) of a package where the dependency is currently limited to the latest minor version. Since Pkg ignores the version field I cannot upgrade it without having a published new version of my dependency.

2

In the (1.0) environment, your example package is required as version 0.1.0. After changing the version to 0.2.0, you’re telling Pkg to resolve package versions - and fails, since at your local dev path only 0.2.0 is available.

I think you’re looking for up:

(jDiscourse) pkg> generate BAR
Generating project BAR:
    BAR/Project.toml
    BAR/src/BAR.jl

(jDiscourse) pkg> st
    Status `Project.toml`

(jDiscourse) pkg> dev ./BAR
 Resolving package versions...
  Updating `Project.toml`
  [1e588908] + BAR v0.1.0 [`BAR`]
  Updating `Manifest.toml`
  [1e588908] + BAR v0.1.0 [`BAR`]

shell> nano ./BAR/Project.toml
# changing the version number

(jDiscourse) pkg> st
    Status `Project.toml`
  [1e588908] BAR v0.1.0 [`BAR`]

(jDiscourse) pkg> resolve
 Resolving package versions...
ERROR: Unsatisfiable requirements detected for package BAR [1e588908]:
 BAR [1e588908] log:
 ├─possible versions are: 0.2.0 or uninstalled
 ├─BAR [1e588908] is fixed to version 0.2.0
 └─restricted to versions 0.1.0 by an explicit requirement — no versions left

(jDiscourse) pkg> up
  Updating registry at `~/.julia/registries/General`
  Updating git-repo `https://github.com/JuliaRegistries/General.git`
 Resolving package versions...
  Updating `Project.toml`
  [1e588908] ? BAR v0.1.0 [`BAR`] ⇒ v0.2.0 [`BAR`]
  Updating `Manifest.toml`
  [1e588908] ? BAR v0.1.0 [`BAR`] ⇒ v0.2.0 [`BAR`]

(jDiscourse) pkg> st
    Status `Project.toml`
  [1e588908] BAR v0.2.0 [`BAR`]

A local non-registered package can never be restricted by a Registry, since it’s not registered - the required version (i.e., 0.1.0) is just not available anymore since you changed the version number to 0.2.0.

EDIT:

It does look like there’s a bug here though, since resolve should already do that. Also, resolve seems to just be a wrapper around up with some arguments.

3

Related question: if I forget to bump the version in Project.toml when I release packages with the current attobot setup, that is at the moment innocuous, except for pkg> status showing wrong versions for dev’ed packages. Is this correct?

4

When the project file is ur d for tagging the version in there will determine what version you tag.

5

I was asking more about the current state of affairs. Specifically, is it OK if I don’t specify a version in Project.toml for now?

6

Currently the version in Project.toml file is only used when you are in a checked out state.

1 Like