Print a hint suggesting `shared = true` if the user does `Pkg.activate("@foo")`

[DilumAluthge]

trafficstars

See #2983 for the motivation.

[mkitti]

Do we need the show_shared_hint? Looking at the code, I think we could bypass it by providing name as a keyword.

Edit: Typing too quickly. I see the other version of activate does not have a name or path as a keyword.

[mkitti]

Is the regex overkill here, could we use startswith instead?

[mkitti]

Could we have shared::Union{Bool, Nothing} = nothing as a default? Then

show_shared_hint = false
if isnothing(shared)
   shared = false
   show_shared_hint = true
end

That way we do not need to add a new keyword. The default is to show the hint. To get rid of the hint, just be explicit that you do not want a shared environment with shared = false.

[MilesCranmer]

It might be good to use the exact same check as is done in the REPL version, just for consistency's sake: https://github.com/JuliaLang/Pkg.jl/blob/02b6f7798bb4263d1fd7255ceeeef24403def650/src/REPLMode/argument_parsers.jl#L201-L203

[DilumAluthge]

Alright, Pkg.activate and ] activate now use the same parsing logic, namely:

1. Determine if it looks like a shared environment by doing first(path) == '@'.
2. If it looks like a shared environment, get the name of the shared environment by doing chop(path; head = 1, tail = 0).

[fredrikekre]

Pkg is already pretty verbose about printing the environment that was activated for essentially the reason that you might have activated the wrong thing (https://github.com/JuliaLang/Pkg.jl/issues/983 etc), isn't that enough?

[MilesCranmer]

You would think, but it evidently wasn't enough for me and the other poster who both posted questions about how to get @ to work in Pkg's functional mode.

Anyways I think more helpful error messages are never a bad idea! (my subjective view is that helpful error messages are the best form of documentation)

[fredrikekre]

If users don't read the current feedback, why would they read the new one?

[MilesCranmer]

The current feedback basically just says the intended behavior (creating a shared env) didn't work. It doesn't say how to make it work!

[mkitti]

The trend would be to put these user friendly features in interactive usage. Could we modify this so that it only affects the REPL mode?

[MilesCranmer]

In the REPL mode I think you would use the normal @pkg_str strategy for adding packages.

Anyways I experienced this issue outside of the REPL (which is why I used the functional API). I don't see any negatives from giving users like me a hint about what they are doing wrong?

I would guess the number of users who misuse @ in trying to declare a shared env is significantly greater than the number of users who have a folder prefixed by @. And at worst for those few (if any!) power users who want to use a folder with a literal @ (and also understands they can't activate it from REPL mode), you are just giving some harmless printouts that they can turn off.