Pkg environment is sticky (Julia v0.7-beta)

Internals & Design
1

I find this a bit annoying

shell> mkdir Test & cd Test

(v0.7) pkg> init # or generate
Initialized project at /home/.../Test/Project.toml

(Test) pkg>

Now if I move on the directory tree, the environment for Pkg is still Test

julia> cd()

(Test) pkg>

Is this intended or is it a bug?

Version info:

Julia Version 0.7.0-beta.7
Commit 0978251 (2018-06-25 01:11 UTC)
Platform Info:
  OS: Linux (x86_64-redhat-linux)
  CPU: Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.0 (ORCJIT, skylake)

In case it is a bug, I’ll just copy paste this into GitHub. Thanks

2

On newest master init will activate the new environment but cd ing into a new environment will not activate it. It requires an explicit pkg> activate command. The reason for this is that it was deemed dangerous to change what code was being loaded based on the mere existence of a file.

It will be possbile to opt into the old cd → activate behavior.

1 Like
3

May I ask, why it is dangerous? Was the file meant Project.toml? Is it similar to the Python case of __init__.py?

4

How could I activate the v0.7 “global” environment without going exactly to where v0.7 project file is?

Thanks

5

That one is active by default. If you pkg> activate you can pkg> deactivate to go back to the 0.7 one.

See discussion in e.g. https://github.com/JuliaLang/julia/pull/27633

2 Likes
6

Not sure if this is 100% relevant to the discussion – I was about to post a new topic, but was directed here. I’m probably just confused, but when I start Pkg interactively (having deleted ~/.julia), I get, say, (foo) pkg> if I have . in my load path (I’ve seen some discussion about that), but if I don’t, I seem to just get pkg> – I don’t see (v0.7) pkg>. And activate doesn’t seem to change anything. (And deactivate doesn’t see to exist…?)

7

See also Is there a replacement for ‘deactivate’? · Issue #464 · JuliaLang/Pkg.jl · GitHub

I wonder if it would be useful to have the stdlibs added as topics under development on discourse.

8

Thanks. Doesn’t seem to solve my issue, though.

9

What I’d your LOAD_PATH and what does Base. active_project() say?

10

Aah, that’s the issue. The LOAD_PATH contains some directories I added myself (by setting JULIA_LOAD_PATH), and Base.active_project() was empty. If I don’t set JULIA_LOAD_PATH in my shell, all is well, it seems, with LOAD_PATH containing @, @v#.# and @stdlib.

I guess there’s some magic here I haven’t picked up yet. The docs still say that LOAD_PATH can be “extended” by defining JULIA_LOAD_PATH, but it seems it’s simply overwritten. I guess this is part of the simplification.

Now, I had no idea that such things as described there were possible (i.e., inserting $JULIA_LOAD_PATH in the shell actually inserting it in Julia, even if $JULIA_LOAD_PATH is empty), so I hadn’t bothered including it. Adding it fixed everything – I should have read #27633 more carefully! (Or … is it just that the path ends with :? That seems to work, too, and is less of a magical explanation.)

Anyway, thanks! :smiley:

11

Sorry, I need to write docs. This design was finalized and implemented last week and I haven’t gotten a chance to document it yet.

12

Fully understandable!