Exactly, that is part of it, with some additions: that using should install the package locally available only. If the user never added the package, I think it is fine to error.
And, in the REPL, the output of the command should be cleaner, it should “almost” feel like a using from the shared @v1.7 environment. Maybe with one line of warning.
I think that is a great way to introduce the environments as a feature, and important feature.
I also tested the MWEs in the base environment, until it became a mess. From then on, I start a new temporary environment every time for that. And I would love to be able to save those at the end.
The more I use Julia, the more I feel that the base environment is like a root account, which I should be very careful in using, where changes can cause widespread confusion in all my development workflows. I feel thus that it should be hidden, not exposed, by default.
So exactly. What would be the downsides of behaving like that?
With that, if the package is not installed anywhere, we can tell the user to install it.
My idea was to have that behavior activated by a draft environment. For instance, the user would do:
% julia --draft
and the environment would be a temporary environment with those options turned on, but where instead of the new macro, the using command would behave like that. With that, scripts would not be environment-specific.
With the additional feature of having a save_environment("my_new_env") feature, with the proper information that then the environment is bounded to the versions of the packages in use at that time (with the advantages that that may bring).
(then I think that this would be a nicer default behavior than the current one, but that’s another story).
One could write that:
A draft environment is fresh environment designed for experimenting and using Julia scripts. It tries to be responsive by not downloading new package versions if local installed versions are available. Adding new packages or updating previous packages must be an explicit action, and require a working internet connection. A draft can be saved into a full featured reproducible environment, in which the package versions used are annotated, with save_env("@new_env"). Draft environments are a good alternative to run package tutorials, plotting, and other tasks that require perhaps large packages to be loaded, but do not involve a heavy involved development workflow.
Yes, although I don’t know if it is possible to modify the behavior of using (keyword).
Also, I think one would need to call the package to activate the changes.
Maybe one can make a make_persistent function, which modifies the startup.jl
Having a package that does those things would be nice, even to experiment how it feels. Even if it is not possible to overwrite using, maybe having @reuse or something like that can provide an idea if the workflow is nice. For instance, one could play around with:
using Draft
@reuse Plots, DifferentialEquations
...
I could try to piece something together. It would probably look like this:
module OfflineEnvironment
import Pkg
export save_environment, @using_and_add
function __init__()
Pkg.offline()
Pkg.activate(temp=true)
end
# helper
function save_environment(target)
isdir(target) && cp(Base.active_project(),joinpath(target,"Project.toml"))
end
macro using_and_add(pkg)
quote
#TODO check if installed
Pkg.add($(string(pkg)))
using $pkg
end
end
end
One nice thing would be to simplify the output of @reuse (or @using_and_add), to something clean and just informative of the version of the package being “installed”, instead of…
(from a functional point of view that seems to do the work quite well )