Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to provide environment at notebook start #1788

Open
j-fu opened this issue Dec 27, 2021 · 4 comments
Open

Allow to provide environment at notebook start #1788

j-fu opened this issue Dec 27, 2021 · 4 comments

Comments

@j-fu
Copy link
Contributor

j-fu commented Dec 27, 2021

I think about something like Pluto.run(notebook=..., project=... ) . This would start the notebook with the environment provided under project instead of the notebook environment. A similar option to Pluto.SessionActions.open and corresponding methods of PlutoSliderServer.jl would be nice.

The main use case is the use of Pluto notebooks as package tutorials which at once are used in the documentation and in CI.

  • Disable PlutoPkg when working in the tree of a package under development. This allows to develop notebook and package in parallel and to take advantage of updates in the package via Revise.jl .
  • Eventually run the notebook during unit tests for a dev'ed package(though this could be achieved by running the notebook as a script)
  • Batch generation of html pages from Pluto notebooks using a not yet registered version of the package during documentation development and deployment.

Outside of these contexts, and without providing an environment, the notebook should run in "reproducible mode" using PlutoPkg with a fixed version of the package.
I find it important that switching between these two modes is possible without changes in the notebook
(like e.g. "markdowning" a cell with Pkg.activate.

In the moment I achieve this behavior in a quite hackish way.
The the initial proposal in #1281 seems to have a similar effect.

A slightly related discussion is found here. EDIT: May be @kellertuer is interested in this as well.

@j-fu
Copy link
Contributor Author

j-fu commented Jan 22, 2023

@ederag
Copy link

ederag commented Jul 24, 2023

I often have one server opened with notebooks belonging to different projects,
so our use cases are probably different, but here is a possible workflow:

Since PR #2018, it is possible to "Disable in file" a particular cell (make it "skip_as_script").
Screenshot_20230724_164354
[note: in the screenshot the current state is disabled, as desired;
the menu says what will happen if it were clicked ("Enable in file")]

That comments out the cell code in the file,
so this activate is ignored by julia when the file is included or for tests,
but the markup tells Pluto that it should use it (and thus activate) when opened as a notebook.

@j-fu
Copy link
Contributor Author

j-fu commented Jul 25, 2023

Yes, this works well when the notebook is part of some project.

My case is a bit different. I figured out that the situation intended with #2614 can be emulated in the following way:

begin
    import Pkg as _Pkg
    haskey(ENV,"PLUTO_PROJECT") && _Pkg.activate(ENV["PLUTO_PROJECT"])
    using LinearAlgebra
    using Plots
    etc etc ...
end

If I give the environment variable PLUTO_PROJECT, it activates that project and ignores what is in the notebook project+manifest. Ignoring is important - in particular they are not removed.

I the variable is not given, we have just a normal notebook.
In this configuration it also can run under CI as a file (for this purpose, instead of includeing I read in the notebook and put a module wrapper around it).

My feeling is however that this behaviour is not guaranteed as a documented feature of Pluto.jl. Nevertheless I will use it for the time being.

@j-fu
Copy link
Contributor Author

j-fu commented Nov 20, 2023

Maybe it is just sufficient to have a switch which disables PlutoPkg and runs the notebook in the environment of the caller.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants