About checking a package/library `Manifest.toml` into control version (again)

General Usage
, , , ,
21

This idea for Pkg to have a date flag is definitely doable, just someone would have to implement it.

There is no need to add this complexity to Pkg. Backdating the registry can be done perfectly well in a separate package.

1 Like
22

I do think registry pin would be a reasonable addition though because it’s easy to implement. Mapping dates to registry trees hashes is a different matter.

2 Likes
23

Just because I figure you’d be interested @goerz, here is how I eventually went from your kind suggestions up there:

EcologicalNetworksDynamics.jl/compat

This introduces 3 testing “flavours”:

  • latest: regular testing with ] test: pick latest compatible versions. Then use CompatHelperLocal.jl to warn about possible new incompatible versions of dependencies in the ecosystem. To be run with latest julia version.

  • lower: Prior to testing, parse the [compat] section of Project.toml and pin all dependencies to the lowest version claimed. Done with this script. To be run with the lowest julia version claimed compatible.

  • pinned: Prior to testing, activate and resolve the environment checked in as ./compat/pinned_test_env/{Project,Manifest}.toml. To be run with the julia version corresponding to this environment. This environment was captured with this dedicated script:

    • Use TestEnv.jl to retrieve one testing environment after a successful latest test run.
    • Pin all dependencies in this temporary environment with Pkg.pin(all_pkgs=true).
    • Copy-paste this environment’s {Project,Manifest}.toml for check-in in ./compat/pinned_test_env/, for later use by “test pinned”.

The first 2 flavours are useful to ensure the widest possible dependencies constraints ranges for package consumers. The third flavour is useful for future bisection / reproducibility.

2 Likes