Pkg.jl: status has no option to show all packages across the environment stack

[krcools]

Only packages available in the top tranche can be queried. Deeper packages are available for using but are not listed.

[fredrikekre]

status --verbose?

[StefanKarpinski]

status --all maybe?

[SimonDanisch]

Maybe just show a hint like:

(pkgtmp) pkg> st
    Status `C:\Users\sdani\pkgtmp\Project.toml`
    This environment is part of stack [v1.1, ...] use st --all to show all available packages
  (empty environment)

this would make it self documenting and much easier to learn about stacked environments ;)

[KristofferC]

I don't think the output of commands is a good place to put documentation. You read it once and then it is annoying.

[SimonDanisch]

I think st is mainly an exploration tool for environments usually outputting tons of text, so I can't really image how anyone could get annoyed by that one line ^^
For a compromise, I do think that the stack part is crucial information we should add - but I see how the "tool-tip" part is more debatable.

[KristofferC]

Stack part is documented at https://docs.julialang.org/en/v1.1/manual/code-loading/#Environments-1 but we can of course add a note about it somewhere.

[SimonDanisch]

Yeah I got that, but I didn't even realize I had to search for it ;)
Also, i meant a note about the current stack, not that stacking exists - which is usefull information, since that can be quite different, no?

[KristofferC]

Sorry, https://docs.julialang.org/en/v1.1/manual/code-loading/#Environment-stacks-1 is a better link.

LOAD_PATH defines the stack (and the current active project in Pkg).

[SimonDanisch]

Yeah, that's documented if you search for it, but why not have a small hint about the current stack in st? It's a crucial part of your environment, and st is the function to call, when you want to learn crucial information about the environment! It's the one and only purpose of st after all :D
Also, the content of LOAD_PATH is pretty verbose:

(pkgtmp) pkg>

julia> Base.LOAD_PATH
3-element Array{String,1}:
 "@"
 "@v#.#"
 "@stdlib"

Is the @ the pkgtmp environment?

[SimonDanisch]

I guess that's the option one wants to call:

julia> Base.load_path()
3-element Array{String,1}:
 "C:\\Users\\sdani\\pkgtmp\\Project.toml"
 "C:\\Users\\sdani\\.julia\\environments\\v1.1\\Project.toml"
 "C:\\Users\\sdani\\AppData\\Local\\Julia-1.1.0\\share\\julia\\stdlib\\v1.1"

[StefanKarpinski]

Agree, we should probably display all packages in the entire load path with some indication of which environment in the stack each one comes from.

[KristofferC]

In 99% of the cases I don't care about my .julia/environments packages when I am in another environment. Showing that for st would be very spammy imo. st --all or something is of course fine.

[SimonDanisch]

Ok, so showing the full path to the toml is by that philosophy also spammy, is it?
Why not show a short version like

(v1.1) pkg> st
    Environment stack: [v1.1, stdlibs]
    ...

(my_env) pkg> st
    Environment stack: [my_env, v1.1, stdlibs]
    ...

This would be even less characters, and I'd argue in 99% of the use cases you wouldn't want to know the full path to the env. For your own env, you just activated it, and "v1.1" and "stdlibs" seem like pretty clear names... If someone pushes a path, one won't be able to show a short version of that, but that seems exactly like the case where it's crucial information, that even though you just activated a new env, some path in LOAD_PATH sneaked in.

[StefanKarpinski]

I think that a st -a would be good. Indicating what's in the environment stack also seems good.

[KristofferC]

I have ~40 packages in my home environment. Showing them all the time on st is spammy yes.

[SimonDanisch]

Oh, maybe there has been a missunderstanding? I'm not arguing for showing the packages, I'm just arguing for showing the stack an env belongs to.
So the output of an empty env would show as:

(pkgtmp) pkg> st 
 Environment stack: [pkgtmp, v1.1, stdlibs]
(empty environment)

Maybe one can indicate in the above, that pkgtmp is the main one, by printing it bold or so ;)

[KristofferC]

I was replying to

we should probably display all packages in the entire load path with some indication of which environment in the stack each one comes from.

[KristofferC]

I don't like showing the stack by default since it is in the majority of cases non-interesting (and show the exact same thing every time). Showing the environment with its packages with a flag seems like a good idea though.

[jekbradbury]

I think something like this would be pretty intuitive; I definitely want to be able to see the contents of the v1.1 environment without deactivating the environment I have stacked on top of it or seeing the entire stack status:

(pkgtmp) pkg> st
Status for pkgtmp in stack [pkgtmp, v1.1, stdlibs]:
(empty environment)
(pkgtmp) pkg> st v1.1
Status for v1.1 in stack [pkgtmp, v1.1, stdlibs]:
  [c52e3926] Atom v0.7.11
  [6e4b80f9] BenchmarkTools v0.4.1
  [295af30f] Revise v0.7.14
  [90137ffa] StaticArrays v0.10.0
  [b8865327] UnicodePlots v1.0.1
(pkgtmp) pkg> st --all
Environment stack [pkgtmp, v1.1, stdlibs]
Status for pkgtmp:
(empty environment)
Status for v1.1:
  [c52e3926] Atom v0.7.11
  [6e4b80f9] BenchmarkTools v0.4.1
  [295af30f] Revise v0.7.14
  [90137ffa] StaticArrays v0.10.0
  [b8865327] UnicodePlots v1.0.1
Status for stdlibs:
  [asdfasdf] LinearAlgebra v1.0.0
  etc.

[StefanKarpinski]

I like that although I would replace "stack" with "load path" (which is currently the only instance of a stack, although it would be nice to generalize the concept in the future). Probably also good to use the standard syntax for projects, expanding @ to the active project and @#.# to the actual major/minor, etc. (but probably not expanding @v1.1 and @stdlib absolute paths for brevity. So maybe something like this, building on your example, @jekbradbury:

(pkgtmp) pkg> st
Status for pkgtmp in load path ["pkgtmp", "@v1.1", "@stdlib"]:
(empty environment)
(pkgtmp) pkg> st v1.1
Status for @v1.1 in load path ["pkgtmp", "@v1.1", "@stdlib"]:
  [c52e3926] Atom v0.7.11
  [6e4b80f9] BenchmarkTools v0.4.1
  [295af30f] Revise v0.7.14
  [90137ffa] StaticArrays v0.10.0
  [b8865327] UnicodePlots v1.0.1
(pkgtmp) pkg> st --all
Load path ["pkgtmp", "@v1.1", "@stdlib"]
Status for pkgtmp:
(empty environment)
Status for v1.1:
  [c52e3926] Atom v0.7.11
  [6e4b80f9] BenchmarkTools v0.4.1
  [295af30f] Revise v0.7.14
  [90137ffa] StaticArrays v0.10.0
  [b8865327] UnicodePlots v1.0.1
Status for stdlibs:
  [asdfasdf] LinearAlgebra v1.0.0
  etc.

[samo-lin]

Please have a look at my answer in this topic.
Moreover, if this issue gets implemented, then it might also affect/simplify the issue discussed here.

[IanButterworth]

I was just burnt by having a rogue Project.toml hiding in a higher directory.

What about put it at the end, with Stacked on in a Pkg color like Status to differentiate it

(@v1.6) pkg> st
      Status `~/.julia/environments/v1.6/Project.toml`
  [6e4b80f9] BenchmarkTools v0.7.0
  [7c2e5008] Foo v0.1.0 `~/Documents/Foo.jl`
  [295af30f] Revise v3.1.15
  Stacked on @stdlib

(@v1.6) pkg> activate Foo
  Activating environment at `~/Documents/Foo.jl/Project.toml`

(Foo) pkg> st
     Project Foo v0.1.0
      Status `~/Documents/Foo.jl/Bar/Project.toml`
  [336ed68f] CSV v0.8.1
  Stacked on @v1.6, @stdlib

(Foo) pkg> activate ~/Documents/Foo.jl/Bar
  Activating environment at `~/Documents/Foo.jl/Bar/Project.toml`

(Foo) pkg> st
     Project Foo v0.1.0
      Status `~/Documents/Foo.jl/Bar/Project.toml`
  [3da002f7] ColorTypes v0.10.12
  Stacked on `~/Documents/Foo.jl/Project.toml`, @v1.6, @stdlib

Maybe @stdlib could be omitted, as that's kind of obvious?