Post-specific environments

[kescobo]

I'm most interested in this for literate notebooks, but it would be nice to be able to have post-specific Project.toml / Manifest.toml. Duplicate of tlienart/Franklin.jl#528.

The primary use-case for me is to be able to have pinned versions of packages / reproducible manifests attached to individual posts.

[tlienart]

You can already do this though?

• have your post folder
• create a subfolder my-post-number-26
• have a file index.md in there with the post content
• have toml files in there
• have the main file index.md actively load these files doing Pkg.activate(...) etc in a code block.

Note that if you do it, you have to do that everywhere, as otherwise the next blog post will use that environment (either that or you need to re-activate the general environment at the end of the blog post).

PS: I'm open to suggestions for doing this differently or having things that can help you do this; but I'm reluctant to enforce every blog post to have a Project/Manifest which would generally seem quite cumbersome.

[kescobo]

Note that if you do it, you have to do that everywhere, as otherwise the next blog post will use that environment (either that or you need to re-activate the general environment at the end of the blog post).

Right, it's doable, but somewhat cumbersome. Perhaps this is a feature that would work in an external package or something? Or maybe I need to just build a new literate function that looks for some option flag and does the activate / deactivate automatically.

PS: I'm open to suggestions for doing this differently or having things that can help you do this; but I'm reluctant to enforce every blog post to have a Project/Manifest which would generally seem quite cumbersome.

I 100% agree with this, that would not be a good experience at all.

[tlienart]

Right, it's doable, but somewhat cumbersome. Perhaps this is a feature that would work in an external package or something? Or maybe I need to just build a new literate function that looks for some option flag and does the activate / deactivate automatically.

hmm actually I think that could be nice. So it's entirely possible to adjust the function literate so that you could call it like

\literate{path; env="path/to/place/with/project/and/manifest"}

if unspecified, nothing happens, if specified it does the activation / deactivation around the call.

Important note: there are some limits to Julia's model of environments, meaning for instance that if you have one post that uses [email protected] and another [email protected], activating/deactivating will not be enough to guarantee that each page uses respectively 0.5 and 0.6. Assuming you're fine with this (could be put in the docs too), then I think the modification to the literate function could be good.

self-note: wouldn't work in multi-threaded pass.

[kescobo]

meaning for instance that if you have one post that uses [email protected] and another [email protected], activating/deactivating will not be enough to guarantee that each page uses respectively 0.5 and 0.6

Interesting. I guess the only way around this would be to start a new julia instance for each post? That could get messy with latency, I guess.

But otherwise, I think this would be really nice.

[tlienart]

If the really nice you're referring to is the ability to have concurrent version, then this is not going to happen.

If you were commenting on the suggestion to have a path passed to the literate command to find relevant toml files, then sure 👍

[kescobo]

If you were commenting on the suggestion to have a path passed to the literate command to find relevant toml files

Heh, that was ambiguous, wasn't it? I meant your suggestion of \literate{path; env="path/to/place/with/project/and/manifest"} would be really nice, even given this limitation.

[kescobo]

If I really desperately need exquisite control over the environment, it's easy straightforward enough (I think, haven't tried) to just use Literate.jl/Weave.jl directly to generate HTML in a separate process, then drop it in.

[tlienart]

Some further thought on this: would you be happy with this being set at page level? i.e.:

+++
...
project = "path/to/Project.toml" # path relative to website folder
manifest = "path/to/Manifest.toml"
...
+++

The page, any code here is executed in an environment matching the project/manifest if provided

if given, the relevant files would be activated/instantiated before executing the page, and de-activated (back to the "main" website environment) after the page execution.

I think that would make more sense than providing specifically to _literate wdyt?

[kescobo]

Yeah, I definitely think that makes sense. In principle, I can imagine situations where you'd want to have multiple different environments, but that seems like a tiny minority of cases, and probably too fiddly to try to support it. This is the kind of thing where a user should probably write their own code to deal with it.

[tlienart]

Right exactly, a user can always just use Pkg as they see fit.

Ok I'll try to figure this one out, thanks for the suggestion, I'll probably reach out to you again to test it 😅

[tlienart]

This is over a year ago and I'd totally understand if you've moved on to other stuff but the feature is now with an example in #197; if you do get a chance to try, lmk and thanks for the feature request!

[kescobo]

Oh, sorry - my ability to work on web stuff really took a nose-dive over the last year! The examples look great, I'll be happy to test this out!