Oh, yeah - this seems like a more sensible way to think about it.
I think this is the primary use of such a thing 
2 Likes
Environment setup is one thing. The other is which of the packages from the environment one actually draws in. So Project.toml and Manifest.toml for the definition of the env, and then include("mystuff.jl"), using mystuff for convenient access to multiple packages with one using.
pkg> resolve will make a Manifest.toml, and so will other package operations on the active project, but I am not sure it should be done by default upon activation and other operations. Pkg can’t really tell if the project needs a manifest or not if there isn’t one.
I think that end users should be aware of the concept. Most scientists embrace the idea of a reproducible environment with enthusiasm.
I really like this idea as well. For precedence, it reminds me of Debian’s concept of “package groups”, although this sounds more flexible.
That might be achieved with something like this… (using this TOML parser for simplicity, but it could be easily written without any external dependency).
using TOML
deps = TOML.parsefile(Base.active_project())["deps"]
for package in keys(deps)
@eval Main using $(Symbol(package))
end
3 Likes
That’s interesting. I had in mind that it’s something very lightweight users could create for themselves. But curated environments specialized to particular domains would be handy, and perhaps more similar to package groups.
I made a Pkg feature request out of this thread Package groups · Issue #1854 · JuliaLang/Pkg.jl · GitHub
3 Likes