The hdf5 and hdf5-sys names on crates.io

[IvanUkhov]

@aldanor writes as follows:

I'm a developer of https://github.com/aldanor/hdf5-rs -- which I've recently got back to hacking on actively and which I'm eagerly planning to bring to a 1.0 state this year. It's quite a hefty crate already, with support for derive-proc-macros for almost all HDF5 primitives including compound types and variable-length types, with built-in thread-safety mechanisms, support for reading/writing multi-dimensional datasets directly from memory, multi-dimensional dataset slicing functionality, ndarray integration, etc (and that's just the beginning). Several people have recently started contributing as well, so my hopes are that the community will pick the pace up and help in shaping the crate.

At the time I was starting it, the "hdf5" name (and "hdf5-sys") were already taken by your crates on crates.io index, so I had to name it "hdf5-rs" (with child crates being "hdf5-derive", "libhdf5-sys", "libhdf5-lib" and "hdf5-types"). Because hdf5_rs would make an unwieldy import name, I've named the library "h5", with the crate being named "hdf5-rs", but that seems to cause confusion as well -- which some users have voiced their concerns about.

With the risk of sounding intrusive, I was wondering whether you'd consider gifting us (hdf5-rs developers) the "hdf5" and "hdf5-sys" names on crates.io index, so we could make it easier on the users, reduce duplication/confusion and increase discoverability (with all crates being named "hdf5-*" now, top-level crate being "hdf5", and imports being under "hdf5::", everything cleanly following Rust conventions). The current "hdf5" crate has no dependents; the "hdf5-sys" crate has 1 dependent ("numeric" crate) - I could talk it over with the owner and ensure smooth migration if needed, but these are all technical details which we could discuss separately if you were inclined positively.

See also #1.

[IvanUkhov]

@aldanor, thanks for reaching out! I’m all for the Rust community having a good package for working with the HDF5 format. I haven’t given much attention to hdf5 and hdf5-sys for quite some time now and, to be honest, have no plans to, as I’m currently not interested in this functionality.

It then makes sense to help others by facilitating their work. If you say that changing the names would eliminate confusion and draw attention to what is actually being actively developed and has great potential, I’ll be happy to transfer the ownerships to you. No question about that!

However, I do want to make sure that it is indeed what the community prefers, and I wasn’t able to infer this from the download counters of hdf5 and hdf5-rs.

Would it be all right with you to get in contact again when you’re close to releasing the first stable version? We’ll then see if there are any concerns raised in this issue.

[aldanor]

@IvanUkhov, thanks for a prompt response!

I've opened aldanor/hdf5-rust#25 - so the folks are free to drop by here and post their opinion if they wish.

First, I wouldn't rely on download counters much since all of the new development on hdf5-rs in the last 2 years has been done on a non-master branch and was never released as a separate version of the crate (as a matter of fact, we're working on that now - a new fully working version will be hopefully released in the coming weeks). (plus, this confirms my previous point on the importance of discoverability)

Would it be all right with you to get in contact again when you’re close to releasing the first stable version? We’ll then see if there are any concerns raised in this issue.

I would make an important distinction between a "stable" version and a "1.0" version here. I'm not sure we're too close to 1.0 now (in my understanding, that implies wrapping and manually testing the majority of HDF5 API for a variety of versions and platforms, which is an enormous task - but not impossible, we're getting there step by step).

However, we're close to releasing a "stable alpha" in the coming weeks - that is, a fully working high-level wrapper that's thoroughly tested on multiple platforms and for multiple library versions, that allows the user to create and navigate h5 files, read and write datasets, wrap their own types, etc. The "stable" here has the meaning "we're not going to rewrite the whole thing from scratch / we test most of what we've published", whereas 0.x-alpha means "we'll definitely change, remove and break some high-level APIs in the future, and there might be some unchecked corners and bugs lingering".

If we're to change the name of the crate (hdf5-rs -> hdf5) and the library (h5 -> hdf5), then, given the chance, I would definitely prefer doing it at the earliest time possible, while the crate still has 0 dependents on the crates index, as it would break every single dependent script out there.

Hoping for your understanding, and thanks again.

[IvanUkhov]

It probably wouldn’t break every single dependent script out there, as the old versions are not going anywhere unless you yank them, but yes, I do understand your concern.

Let’s then follow up in a week or two. Does it sound fair to you?

[Enet4]

As a potential user of hdf5-rs who has waited more than a year to see the upcoming release, I am in favour of making crate names as uniform as possible in this solution, and preferably taking the most discoverable and intuitive namespace that is hdf5. This library can both write and read hdf5 files, presenting itself as an additional milestone towards Rust for scientific computing. An alternative to this would be occupying the crate name h5 instead, but I understand the possible reluctance of doing so.

[aldanor]

Let’s then follow up in a week or two. Does it sound fair to you?

Deal 👍

[jneuff]

Following the discussion above, I'm all for freeing the crate name hdf5 for https://github.com/aldanor/hdf5-rs. It certainly looks like it's going to be the only obvious choice for working with HDF in Rust in the forseeable future. Moreover, making the naming transition as soon as possible would be the least painful option for everyone involved.

[iicurtis]

It would be awesome to see the active hdf5-rs use the hdf namespace. The downloads have now exceeded this unmaintained crate, and a quick search for hdf5-rs on github reveals people are not pulling from crates.io, but rather, they use the git repo for the unreleased 0.3.0. As far as I can tell, version 0.3.0 is waiting on acquiring this namespace (and one other ticket) before release, making this a circle. I'm in favor of switching to hdf5-rs.

[aldanor]

@IvanUkhov Hey, apologies for the delay - I'm back with some updates :) I've fixed most points on aldanor/hdf5-rust#24 list, including removing one of the crates and reworking the build system, so you could say it's now in a pretty stable state (lots of work ahead still of course).

Would you be up for the aforesaid migration anytime soon? In which case we'll need to discuss how to best handle it operationally, and whether the current hdf5/hdf5-sys would be yanked or not (in the latter case, we'll have to bump hdf5-rs to at least 0.5.0a so it shadows the currently available hdf5 0.4.1 crate after being renamed to hdf5 - this may end up being quite confusing though...).

Thanks!

[IvanUkhov]

Done! I’ve added you as an owner of both hdf5-sys and hdf5. I leave it up to you to decide how to proceed operationally. Thank you for driving this project forward!

[IvanUkhov]

@aldanor, I must say that it would be great if everything that depends on the current version (might not be visible on crates.io) continued to work as before. Version 0.5 might not be such a bad number to start with 🙂 But again, it’s in your hands now.