Version-named manifests by default?

Internals & Design
1

Julia 1.11 supports versioning by manifests, but one has first to manually rename the manifest to use this feature.

Should not all newly created manifests be created with the versioned name?

8 Likes
2

Very much in favor of this. If this is considered a braking change, perhaps use an environmental variable or command line parameter to enable this feature?

And if I want to submit an issue for this, should it be an issue for Pkg.jl or for Julia itself?

1 Like
3

I don’t see in which way it could be a breaking change

1 Like
4

We also want to use the version recorded in the manifest to launch the correct Julia version via Juliaup eventually, and this proposal would probably make this more complicated, so I think I’m not in favor :slight_smile:

5 Likes
5

Having non-versioned Manifest and changing between Julia versions, especially if “downgrading” Julia, can result in compatibility issues. That was the reason behind the introduction of the versioned manifests in the first place, if I understand that correctly.

I’d say, for launching Julia over Juliaup: by default start the latest stable Julia version of those registered in (multiple) manifests, otherwise let the user decide.

P.S. Having some indication under which Julia version an environment has been used the last time could be another solution. E.g. writing the date into the corresponding manifest each time, or let juliaup write date + Julia version into a separated file (personally I think it’s not worth it however).

1 Like
6

Why that? Why not using the version in Project.toml, and if there are multiple versions then use the newest stable version that is installed? In most cases a Manifest.toml file is only working for one Julia version.

If you want to look at the Manifest files to decide which Julia version to use, you could also:

  • check all versioned Manifest files and use the one with the highest, stable version
  • if no versioned Manifest file exist, use Manifest.toml
1 Like
7

Whether versioned manifests are created by default or not, there is already probably a substantial proportion of users who are using this feature, especially under those users who do switch between different Julia versions.

2 Likes
8

I am not in favour of writing the last access date in the manifest itself as this would then make version control see the file as changed. Recording this in a separate file would be acceptable, maybe the best place to put this would be in the ~/.julia directory as it then would be user/machine specific and would not clutter the working directory.

I agree that defaulting to the latest available stable version that has a manifest file would also make a lot of sense

1 Like
9

sorry, but is it advised to store manifest.toml in version control?

10

When it is part of a package, then I normally don’t, but when it is part of an environment for some independent scripts then I usually do. I expect that a lot of people do like me. It is nice to be able to recreate the exact environment for scripts, whereas packages should be made to be able to run with any package versions that they are compatible with. As far as I know, there is no official recommendation regarding this, it is the developers choice.

1 Like
11

When I have tested a new version of my packages, I create a copy like “Manifest-v1.11.toml.default” and commit that copy to git. So I always have a copy of the last, working manifest.

But I use it only if things go wrong. Normally I use Project.toml only.

1 Like