What to do after renaming a package? about general HOT 10 CLOSED

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.

from general.

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.

from general.

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

from general.

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.

from general.

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?

from general.

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?

from general.

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.

from general.

JuliaLang/Pkg.jl#726 for reference

from general.

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

from general.

Closing, due to #5000 (comment)

from general.