The maintainer of Snappy.jl (a wrapper of a C lib for a compression format) seems to be MIA. The package should require very little maintenance as it is a very simple wrapper, however the current version does not use binary builder and this has been causing problems. There is already one package which seems to have bypassed it and used
Snappy_jll directly… I’m not sure how direct a dependency in that case but it’s unfortunate for people to have to resort to that.
Anyway, at this point I think it’s about time to give up on the original maintainer and create and register a fork
I’ve opened this thread to give people an opportunity to object or otherwise comment. I’d also prefer to get this into the JuliaIO github organization to increase the truck factor, so if you have permissions in that organization and would like either for me to create the repo and transfer it to you or to invite me, please comment here or contact me directly.
This is a situation similar to What is the disputes procedure for packages? · Issue #25367 · JuliaRegistries/General · GitHub, which was eventually solved by moving the repository to an organisation. I’d argue against forking packages if possible.
Forking of course does not seem ideal to me either, but it seems better than letting it languish in this state for all eternity. If you think it would be worth opening an issue in the registry to override the existing registration for the
Snappy.jl name, I will do so, but if we are going that route I’d feel better about it if we could get it in JuliaIO or another github org.
I just pinged the author via email. What GitHub org would this fall best under?
JuliaIO perhaps, he’s already a member there. But we have this problem with basically all of his packages. It’s totally understandable he doesn’t have the time anymore to maintain them, but the solution is well known and this keeps happening every now and then.
Yeah, I think JuliaIO, all the other compression codecs are there.
Any update on this? It would be really great to be able to utilize the snappy_jll when installing Snappy.jl since right now I have go jump through some really hacky hoops to get it working in a container.
Snappy.jl is still seemingly dead. I’ll poke my head out on slack and see if anyone wants to deprecate it from general, otherwise, I’ll fork it as Snappy2.jl.
I followed up once again, let’s give it until the end of the week, and then I agree that it makes sense to fork and re-name.