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!