Rename package

[iamed2]

Perhaps to IterTools.jl?

JuliaLang/julia#21969 isn't fixed so devs are removing Iterators.jl dependencies in favour of copying code in (e.g. JuliaMath/Combinatorics.jl#49). This has been a headache ever since the introduction of Base.Iterators and at this point the easiest solution might be to rename this package (with a redirect or pointer from the old name to the new name so existing dependencies aren't affected).

@tkelman thoughts?

[tkelman]

I knew using the same module name in base was a bad idea.

Would be effectively a new registration under the new name, either via a repo rename or copying the code (and history?) to a new repo.

[iamed2]

So steps might be:

1. Copy the repo and mess with the git history so it was always called IterTools.jl
2. Push to JuliaCollections/IterTools.jl
3. Register that package on METADATA including all the old tags
4. Add deprecations to JuliaCollections/Iterators.jl with something like an init method that shows a deprecation warning pointing to the new package and a big note on the README, and tag that version as the last

[davidanthoff]

1. Copy the repo and mess with the git history so it was always called IterTools.jl

You could just copy the repo and delete all tags, and then start with a new and fresh v0.1.1. That way you wouldn't have to mess with the history at all, there would just be a lot of commits in the repo before the first tag in which the package had a different name, but those should do no harm.

[ararslan]

One of the JuliaStats packages has been named MCMC, Lora, and now Klara, so we could take inspiration from however that was done.

[tkelman]

In that case the author really wanted to keep the issues, PRs, and github stars associated with the new name, so it was done in not the greatest way. I don't think that's all that important here?

[iamed2]

You could just copy the repo and delete all tags, and then start with a new and fresh v0.1.1. That way you wouldn't have to mess with the history at all, there would just be a lot of commits in the repo before the first tag in which the package had a different name, but those should do no harm.

It would be nice if packages could still depend on old versions but use the new package, requiring minimal updates for package devs.

[tkelman]

If you want to mess with the history like that in a new separate not-yet-registered repo, go ahead. The only package that has upper bounded Iterators is NURBS.jl.

[iamed2]

The only package that has upper bounded Iterators is NURBS.jl

That's a good fact to know!

[ararslan]

We should definitely do this, preferably in short order, as the name conflict with Base is causing all sorts of annoying issues and there will soon be a 0.6.0 release (presumably).

[iamed2]

Alright, I'll get on it now

[ararslan]

Thanks so much, @iamed2, much appreciated!

[iamed2]

JuliaLang/METADATA.jl#9825

I found a tool for issue migration but I am having trouble installing it at the moment.

[musm]

Is it not possible to just fix the underlying issue, instead of trying to sort out a temporary work around (or is the underlying issue too complex to properly resolve)? IMO it is probably pretty confusing to be first recommended to transition to Iterators and then IterTools within basically the same cycle.

[iamed2]

IMO it is probably pretty confusing to be first recommended to transition to Iterators

I'm not sure what transition recommendation you're referring to here.

Is it not possible to just fix the underlying issue, instead of trying to sort out a temporary work around (or is the underlying issue too complex to properly resolve)?

There have been a few attempts (this first reared its head with Dates) but continued issues. I expect the underlying issue to be solved eventually, but in the meantime this works. It's also just confusing to have a package with the same name as a Base module (if someone says "Iterators" it's not clear which they mean).

[ararslan]

I expect the underlying issue to be solved eventually

Indeed, though in this case the underlying issue hasn't even yet been concretely identified.