What to do after renaming a package?

[tkf]

I moved my package from https://github.com/tkf/ProgressMeterLogging.jl to https://github.com/tkf/ConsoleProgressMonitor.jl and re-registered it with a different UUID. ProgressMeterLogging is still installable presumably because github redirects the old repository to the new one. I renamed old tags so the old release of ProgressMeterLogging.jl is "rooted" (and it's accessible via ConsoleProgressMonitor#master anyway).

But are there any other actions I should take after re-registration? In particular:

• Should I re-create the old repository (https://github.com/tkf/ProgressMeterLogging.jl) with all the releases? (and maybe archive it afterward.)

• Is there any recommended way to discourage people from installing the old package? Ideally, Pkg.add should fail and it should not be listed in pkg.julialang.org (although it looks like it hasn't been updated for a while ATM). An approximation I can implement is to recommend installing the new package via @error in __init__ of the old package.

[oxinabox]

It is fine.
You've done enough.
You've done the right things.
You have done the right thing by renaming it in github, so the issues and releases and redirects are preserved.

At some point people will decide to to check for a new update,
or will want an issue,
and they will go to the old URL and github will redirect them and all is well.

You could be like FiniteDifferences.jl and list the old name in the readme
https://github.com/JuliaDiff/FiniteDifferences.jl#fdmjl

Making it error for no reason doesn't seem useful.
That would be a breaking change and thus most people wouldn't see it anyway.

[tkf]

Thanks, good to know that I'm on the right track.

Making it error for no reason doesn't seem useful.
That would be a breaking change and thus most people wouldn't see it anyway.

I was proposing to print an error-level (or warn-level) log message, rather than throwing an error. As this would be done only once at the import time, I think it does not disturb standard usage (hence can be done with a minor version bump).

I don't think it is a crazy idea to implement a way to discourage installing a package or a particular version of a package. For example, Python devs are doing similar discussion: PEP 592: Support for "Yanked" Files in the Simple Repository API - Packaging - Discussions on Python.org

[oxinabox]

shrug logging a warning is permitted, yes.
but from experience, log messages in in __init__ are incredibly annoying.
because sometimes __init__ gets run many times.
(Not sure if it is a bug or not, but on big dependency trees I have seems some warning printed dozens of times.)
I think it also really slows down code loading by triggering some kinda of bad task swap, but I have never proved it.

[tkf]

log messages in in __init__ are incredibly annoying

Well, being annoying is kind of a purpose of @error/@warn. OK, probably not incredibly annoying.

sometimes __init__ gets run many times

Maybe that's from precompilation? Maybe logging message in __init__ should check ccall(:jl_generating_output, Cint, ()).

I think yanking releases need properly handled by Pkg without an annoying hack like this. But I guess I should open it in Pkg instead.

[oxinabox]

Aside:

I don't think you are using the work Yank the same way Pkg/the registry uses it.
Yanking is for removing malicious package releases.

You don't want to remove the old release do you?

[tkf]

I'm using it in PEP 592 sense. I didn't know that yank already has some meaning in Pkg.jl. So it can't be used for known-to-be-broken releases that are still available if listed in Manifest.toml?

[fredrikekre]

Pkg's yank is similar to cargo yank (https://doc.rust-lang.org/cargo/reference/publishing.html#managing-a-cratesio-based-crate) but looks like python yank is similar.

[fredrikekre]

JuliaLang/Pkg.jl#726 for reference

[tkf]

Thanks, I think yank implemented in Pkg does what I want.

[tkf]

Closing, due to #5000 (comment)