“Partial” Package management – exclude one package from Plutos package management?

[kellertuer]

I currently have a slight problem with the (otherwise superb) package management of Pluto.
I am using Pluto & PlutoStaticHTML to generate my tutorials, for example https://manoptjl.org/stable/tutorials/Optimize!/

Currently they use Plutos management for packages, now the problem is:
If either we have a breaking change (I am working on one right now) or introduce a new feature/function and want to have that in the tutorial, that is both not compatible with rendering that in the docs, since the PR would be at e.g. 0.4.0 (the tests run with 0.4.0 ofr example) but the notebook still at version 0.3.23 of the package the tutorial is for.

This means that new features can only be described in a tutorial in the version after they are introduced, and for breaking changes, like the version 0.4.0 that all tutorials of that version are still on version 0.3.23 and only 0.4.1 would be able to feature tutorials for 0.4.0 (but actually not for 0.4.1 itself, if that introduces more than just updating tutorials).

What would be a good way to resolve this?
My favourite way would be to exclude this single package from Pluto package management and load it from the global environment (though that contradicts a little bit the reproducibility idea, I know).

Why ideas what one could do about that?

[rikhuijzer]

As also mentioned in JuliaPluto/PlutoStaticHTML.jl#158 (comment), it's probably best to use Pkg.activate manually. For example, use:

begin
    using Pkg
    Pkg.activate(; temp=true)
    packages = [
        PackageSpec(; name="AlgebraOfGraphics", version="0.6"),
        PackageSpec(; name="CairoMakie", version="0.7"),
        PackageSpec(; name="CSV", version="0.10"),
        PackageSpec(; name="DataFrames", version="1.3"),
        PackageSpec(; name="GLM", version="1.6"),
        PackageSpec(; name="HypothesisTests", version="0.10"),
        PackageSpec("PlutoUI")
    ]
    Pkg.add(packages)
end

This gives complete control over the dependencies and is explicit. Note that explicit is generally good in software engineering (e.g., https://dmitripavlutin.com/explicit-coding-discipline/).

[kellertuer]

No that does not help, since with that I still can only install packages that are registered, for a PR when working on a new tutorial for a new version, that will not work.
Especially the version I would like to use is activated in the (non-temp) Pkg default environment I am starting Pluto from. So starting a temp and loosing the development version (locally or on CI) is not what I would like to have, since the whole goal here is to update a tutorial to a new (possibly breaking) version while that is developed.

[disberd]

You could probably modify your tutorial notebook to point to a specific commit hash on github that contains the updated code before the version new version is tagged (you can modify a notebook environment to add a specific version of a package directly from github with Pluto.activate_notebook_environment.
After you pushed the breaking change on github, you update the tutorial notebook to use that specific commit and push a new commit with just the updated tutorial.
You then release the new version with this second commit and you should be able to have the updated tutorial with correct functionality in the published release (all speculation, did not actually try it right now as it's a bit late).
It is a bit more manual than just disabling a single package but it basically achieves the end goal you have and also ensures reproudicibility as it's pointing to a specific commit (rather than a branch)

[disberd]

@kellertuer i tried again the approach I suggested above (activating the notebook environment and adding a custom package version by pinning a specific github commit) and it indeed works and should keep the package fixed to the unreleased version until you don't trigger full update of the notebook package versions from Pluto (at which point you have to redo the procedure)