Update Project.toml compat entries in Pluto

I have a Pluto notebook created in Julia 1.5 and then used in 1.6. It includes a Project.toml and Manifest.toml in the jl file.

With Julia 1.8 there were a lot of errors. I then did a Pkg.update within Pluto and it got rid of the errors. However some of the packages cannot update to the most current version because of compat entries.

The documentation says to look for the up arrow in the circle to update packages. I cannot find this up arrow in a circle, and even if I can, I am not sure that this will enable editing the compat entries. I am looking for a way to do update the compat entries from within the Pluto environment.

The compat section of the file as viewed in a text editor shows

[compat]
CSV = "~0.9.4"
FFTW = "~1.4.5"
Plots = "~1.22.2"
PlutoUI = "~0.7.11"
Tables = "~1.5.2"
"""

The command within Pluto

Pkg.status(; outdated=true)

gives the results

Status `C:\Users\jakez\AppData\Local\Temp\jl_oBv0nu\Project.toml`
⌅ [336ed68f] CSV v0.9.11 (<v0.10.4) [compat]
⌅ [7a1cc6ca] FFTW v1.4.6 (<v1.5.0) [compat]
⌅ [91a5bcdd] Plots v1.22.7 (<v1.31.7) [compat]
⌅ [bd369af6] Tables v1.5.2 (<v1.7.0) [compat]

Thanks in advance

I think you should be pretty safe editing the compat entries manually, and then updating the notebook environment again.

Thanks, I did edit them manually based on the compat manual section you referenced. I removed the tilde’s and the quotes at the end of the lines like this.

[compat]
CSV = "0.9
FFTW = "1.4
Plots = "1.22
PlutoUI = "0.7
Tables = "1.5
"""

I then loaded the notebook again and did Pkg.update() and Pkg.resolve() though I don’t think I need to do that. When I looked in the compat section of the file the packages updated but the tildes and quotes came back as shown:

[compat]
CSV = "~0.10.4"
FFTW = "~1.5.0"
Plots = "~1.31.7"
PlutoUI = "~0.7.39"
Tables = "~1.7.0"
"""

Then I removed the Compat section from the project.toml and it continues to work.

I think Pluto automatically adds tilde specifier to improve environment reproducibility, since they are more restrictive than caret specifiers. So the errors probably come from compatibility issues between the packages: what kind of errors are they?