Idea: guided Project.TOML editor with [sources]

[fonsp]

There is some missing functionality in the Pluto package manager:

1. dev a local package
2. add a package from git with a branch
3. add a package at a specific version
4. custom update: update just one package, update to something other than latest, or downgrade

In https://github.com/fonsp/Pluto.jl/pull/2245 we worked on a GUI approach to address this, where you can specify the command for a package (e.g. dev ~/Documents/Example.jl or add [email protected]).

Julia 1.11 has a new feature, [sources] in the Project.toml. https://github.com/JuliaLang/Pkg.jl/pull/3783 With this feature, you are able to achieve all 4 tasks :) And it's great that it uses an existing Julia feature, and requires less "Pluto magic" to make it work. This also improves maintainability, and it might make integration with other (3rd party) tools easier.

The idea is to add a Project.toml editor in Pluto. 🌸 This allows the user to modify compat and sources entries manually to achieve these goals.

[deps]
FileIO = "5789e2e9-d7fb-5bc7-8068-2c6fae9b9549"
Images = "916415d5-f1e6-5110-898d-aaa5f9f070e0"
Plots = "91a5bcdd-55d7-5caf-9e0b-520d859cae80"
PlutoUI = "7f904dfe-b85e-4ff6-b463-dae2292396a8"

[compat]
FileIO = "~1.15.0"
Images = "~0.25.2"
Plots = "~1.31.7"
PlutoUI = "~0.7.40"

Smaller API

A benefit of this, just like https://github.com/fonsp/Pluto.jl/pull/2245, is that it leverages existing Pkg functionality. Pkg can be hard to work with as an API, since it is mostly designed to interface via Terminal UI and TOML config files, and public API is too limited. That's why we have so much compat code in https://github.com/fonsp/Pluto.jl/blob/main/src/packages/PkgCompat.jl. Each new Julia version takes a lot of work to patch Pluto (see e.g. #2928), and the Pkg integration is often affected.

Project.toml is public API, and TOML is a well-defined spec, so it is much more future-proof.

https://github.com/fonsp/Pluto.jl/pull/2245 is based on Terminal UI which has the same benefit! A disadvantage is that the implementation still uses some private Pkg API to check and execute the commands.

Julia 1.10

[sources] is not supported by Julia 1.10. @disberd and I talked about maybe writing a polyfill.

Cases

Updating

In the compat bounds, we can add an inline widget that you can click to set compat to the latest version.

Checking

We can check that each imported package is listed as [deps], and that it has a compat bound.

Local and git

With [sources], you can set packages to use local files and git

New packages?

What to do when you:

• Typed a new import but you did not run it yet? (niceee)
• Added a new dep but did not import it yet?

Auto management?

[j-fu]

A disadvantage is that the implementation still uses some private Pkg API to check and execute the commands.

Did you discuss this with the Pkg.jl maintainers ? May be there is a way to make these part of the public API of Pkg ?

[fonsp]

I made a prototype!

https://github.com/user-attachments/assets/eb498f8a-39ce-4a12-b657-386da1e544eb

But without https://github.com/JuliaLang/Pkg.jl/issues/4086 the usefulness is limited

[mossr]

This is awesome! Any word on when/if this will be included in a newer Pluto version?

[fonsp]

It will take some time! You could help by contributing to https://github.com/JuliaLang/Pkg.jl/issues/4086 and I'm trying to improve our Pkg-related codebase a bit before this feature.

[fonsp]

Still waiting for the Pkg issue.

In the meantime I reworked our Pkg code a bit: #3185