Pkg.jl: Additional Manifest entries

Created on 19 Oct 2019  路  2Comments  路  Source: JuliaLang/Pkg.jl

From Slack,
Manifest.toml should contain all the needed information in order to recreate an environment. However, a key piece of information used in solving the graph is not tracked: the Julia version. We should start including an entry on the Manifest for the Julia version used. When recreating an environment using instaniate -m, it should warn if the Julia version is different from the one used to create that Manifest.toml.

Most helpful comment

Reposting what I wrote in #2508 as I didn't find this first


It seems a fair few issues with upgrading to 1.6 have been around using old manifests that fail in unclear/unpleasant ways (because of changes to stdlibs for one), and the advice is "manifests aren't guaranteed to work across julia versions, delete the manifest and try again".

For 1.7 given there's no guarantee of cross-version manifest compatibility, I was wondering if a clean break could be made and change the structure of the manifest & Manifest.toml to something a bit more flexible than a Dict{UUID,PackageEntry} so that metadata can be added, like julia version and a hash of the Project.toml so that Pkg can be sure that the manifest is a valid resolve of the current project.

A heuristic could be added to 1.6.1 to read_manifest to detect if the manifest is of the new format, to warn/instruct the user to delete the manifest to proceed.

The new manifests would break if users tried to use them with older julia versions. But perhaps that's part of the no guarantee?

All 2 comments

We could also warn on activate if the version is different

Reposting what I wrote in #2508 as I didn't find this first


It seems a fair few issues with upgrading to 1.6 have been around using old manifests that fail in unclear/unpleasant ways (because of changes to stdlibs for one), and the advice is "manifests aren't guaranteed to work across julia versions, delete the manifest and try again".

For 1.7 given there's no guarantee of cross-version manifest compatibility, I was wondering if a clean break could be made and change the structure of the manifest & Manifest.toml to something a bit more flexible than a Dict{UUID,PackageEntry} so that metadata can be added, like julia version and a hash of the Project.toml so that Pkg can be sure that the manifest is a valid resolve of the current project.

A heuristic could be added to 1.6.1 to read_manifest to detect if the manifest is of the new format, to warn/instruct the user to delete the manifest to proceed.

The new manifests would break if users tried to use them with older julia versions. But perhaps that's part of the no guarantee?

Was this page helpful?
0 / 5 - 0 ratings