deprecate Pkg.activate do-block syntax from public API

[IanButterworth]

This is what was decided in https://github.com/JuliaLang/Pkg.jl/pull/2639 cc. @st-- @fredrikekre

% ../julia/julia --project --depwarn=yes
...
julia> import Pkg
[ Info: Precompiling Pkg [44cfe95a-1eb2-52ea-b672-e2afdf69b79f]

julia> Pkg.activate("/tmp/123") do
       Pkg.status()
       end
┌ Warning: `activate(f::Function, new_project::AbstractString)` is deprecated, use `Operations.activate(f::Function, new_project::AbstractString)` instead.
│   caller = top-level scope at REPL[2]:1
└ @ Core REPL[2]:1
Status `/private/tmp/123/Project.toml` (empty project)

But does it achieve the right message? It's not saying "don't use this", just "use this other function". Perhaps @deprecate needs a warn_against = true mode that says something like:

┌ Warning: `activate(f::Function, new_project::AbstractString)` is deprecated, this functionality should not be used but  `Operations.activate(f::Function, new_project::AbstractString)` does exist as a replacement.
│   caller = top-level scope at REPL[2]:1
└ @ Core REPL[2]:1

[st--]

@IanButterworth yes it'd be great if @deprecate had a more explicit warning against usage as you suggest. That's unlikely to happen anytime soon, so how about the following instead? Add an (unexported)

function _deprecated_activate(f::Function, new_project)
    @warn "You should not use this form [maybe short explanation why]"
    Operations.activate(f, new_project)
end

and then

@deprecate activate(f::Function, new_project::AbstractString) _deprecated_activate(f::Function, new_project::AbstractString)

(This is based on my understanding that Operations.activate is needed by Pkg-internal code and hence shouldn't raise a warning.)

[IanButterworth]

That's unlikely to happen anytime soon

Why? If people like the idea we could add the feature for 1.8

[st--]

That's unlikely to happen anytime soon

Why? If people like the idea we could add the feature for 1.8

Well, "soon" is relative - extrapolating from the last few releases, it'd be about mid to late summer, I just thought you might want to merge this PR in sooner than that, so wanted to provide a low-effort suggestion that might work well enough until a @denounce macro is available.:)

[IanButterworth]

I don't think deprecation like this would be backported, so the earliest this would land would be 1.8, so both can happen at the same time

[giordano]

For what is worth, we use this Pkg.activate method in BinaryBuilder: https://github.com/JuliaPackaging/BinaryBuilderBase.jl/blob/e1345f7ee6c57b9e263723ce8d02970cbc7d2bfd/src/Prefix.jl#L453

[fredrikekre]

For what is worth, we use this Pkg.activate method in BinaryBuilder:

It is invalid if the user doesn't have the default LOAD_PATH, so that code should probably be fixed then.

[fredrikekre]

Same with the two uses inside of Pkg here btw.

[IanButterworth]

What if instead we fixed it with something like

function activate(f::Function, new_project::AbstractString)
    activate(new_project)
    try
        f()
    finally
        activate(prev = true)
    end
end

[fonsp]

Not sure if it's too late to object, but there is currently no public API to query/manipulate an environment that is not the current environment. I believe this is very useful, and our particular use case is the Pluto server process, which maintains multiple project environments in parallel.

The argument for removing this behaviour is that changing environments dynamically is not recommended. But then why do we have Pkg.activate(::String)?

Ideally, I would like Pkg.Types.Context to be public API. (In internal Pkg API, Context is always the first argument to any function, e.g. Pkg.API.add(context, ["Plots", "Test"]).) This is easy API to manage multiple environments, and it does not modify Base.LOAD_PATH.

[fredrikekre]

Not sure if it's too late to object, but there is currently no public API to query/manipulate an environment that is not the current environment. I believe this is very useful, and our particular use case is the Pluto server process, which maintains multiple project environments in parallel.

For the same Julia process? In any case, what is wrong with working with LOAD_PATH? Then you can actually get what you want, which Pkg.activate doesn't, unless LOAD_PATH contains certain things.

The argument for removing this behaviour is that https://github.com/JuliaLang/Pkg.jl/pull/2639#issuecomment-865965532. But then why do we have Pkg.activate(::String)?

I am fine with removing that too -- I have never used it myself.

[fonsp]

Please don't remove Pkg.activate! 👀 That's not what I meant at all