Should the CurrentEnv path be set at julia startup and not follow with the pwd?

[KristofferC]

Opening this issue after some discussion on slack.

Currently, the CurrentEnv in LOAD_PATH (the one that says what project file you should use based on your path) looks at the pwd of the julia session. This means that if you cd somewhere and there happens to be a project file there, you will load packages for that project. Or if you cd somewhere where there is no project, you will start loading from the NamedEnv.

It could be argued that tying code loading to pwd is a bit brittle and that the path should be set at julia startup and require some explicit invokation to update to the current pwd would make it less likely to be consfused about what environment you are currently in.

cc @mortenpi, @quinnj, @davidanthoff, @StefanKarpinski

[StefanKarpinski]

The consensus on Slack seems to be that using the initial pwd() would be better and having some explicit function for changing the current working directory. Bikeshed: what to call the function/command to change the current env directory?

[davidanthoff]

I think using pwd() by default is great, but it might also be useful to have either a command line argument to pass an explicit path, or maybe an environmental var?

If there is a way to change the env from within a julia session, would that be allowed at any point? Even if one has loaded a package already?

[StefanKarpinski]

You can use JULIA_LOAD_PATH to change it to anything you want. Inside of a running Julia session, you can manipulate LOAD_PATH to get the same effect.

[DrKrar]

I think it would be nice if the CurrentEnv does not change merely just for the current path. It would be nice if there is an explicit way to do this.

[StefanKarpinski]

Adding command line options to control this conveniently is definitely in the plans. Some discussion is needed about what they should be called and how they should work, of course.

[staticfloat]

what to call the function/command to change the current env directory?

I would vote forPkg.activate(). It's similar to python's virtual environments, and sounds cool.

[StefanKarpinski]

See also JuliaLang/Pkg.jl#360: I'm not familiar with direnv but I do think we need to have an explicit step to "bless" an environment for automatic loading and/or activation.

[KristofferC]

Triage didn't reach a decision here, punting for next week (when more people are on the call).

[StefanKarpinski]

#27633 changes this to be resolved early: @ in JULIA_LOAD_PATH is expanded at startup time to Base.current_env(). However, it also removes it from the default LOAD_PATH, which after that PR is just ["@v#.#", "@stdlib"], i.e. a named environment for the current Julia version and the standard libraries. With that PR someone can do the following in their shell to prepend the current environment to their load path:

export JULIA_LOAD_PATH="@:$JULIA_LOAD_PATH"

This works whether JULIA_LOAD_PATH is defined beforehand or not since an empty entry in JULIA_LOAD_PATH is expanded to the default contents of LOAD_PATH.

[KristofferC]

I don't think this is resolved yet since some new things got merged.

[StefanKarpinski]

It got deresolved. The current situation is that @@ is in the default load path and acts like the old CurrentEnv. I still think that it should not be in the default load path. One of the action items to fix that was to implement pkg> activate which we did; the other was to fix the travis/other CI scripts that relied on the current behavior; I asked for some feedback on that on Slack but didn't get any so I didn't want to break everything in the beta. Unfortunately, that means that we either leave things as in 0.7/1.0 final and have a potential security trap in Julia OR we have to change this before RC1 which will be fairly breaking. I still don't really understand what needs to be done on the travis/CI script side.

[JeffBezanson]

Does this still block 0.7?

[StefanKarpinski]

It does but it's fixed.

[ufechner7]

StefanKarpinski wrote:

The current situation is that @@ is in the default load path and acts like the old CurrentEnv.

Is that still the case?

[StefanKarpinski]

No, the current situation is that by default LOAD_PATH = ["@", "@v#.#", "@stdlib"] which gets expanded to:

1. Your current active project (if any)
2. ~/.julia/environments/v0.7/Project.toml
3. the location of the standard library.

The initial active project can be set by the JULIA_PROJECT environment variable and the new --project command-line flag. If you just pass --project then the project containing the current working directory when you start up julia is the initial active project.