Extreme bikeshedding - Renaming UnROOT.jl package?

[Moelf]

This came up in a conversation with @jblomer and @jpivarski at CHEP 2024, I would like to at least start thinking about this immediately, we don't have to rush to a decision of course. I have also talked to @peremato and @graeme-a-stewart today in-person.

The main argument for renaming "UnROOT" is that one may think this package defines itself by being "NOT something", instead of positively being something. I think when @tamasgal first came up with the name, it was at least partly because it's an synonymous with uproot (https://www.merriam-webster.com/dictionary/unroot):

: to tear up by the roots : eradicate, uproot

I also learned from @jpivarski today that, uproot was actually \mu p(y) root. In any case, I think we can at least entertain the idea of renaming this package -- if we're ever going to do it, we should do it pre v1.0.0 release

New name candidates

we thought of and rejected a few options:

• ROOT.jl -- used for the C++ wrapper, maybe should be reserved for pyROOT counterpart
• JROOT.jl -- JROOT is something in Java
• RNTuple.jl -- but we also do histogram I/O and stuff

I think part of the difficulty is that it's very hard to summarize what this package does without referring to ROOT, and once you refer to ROOT, there aren't many choices / you have to avoid being confused with ROOT wrapper. More name suggestions are welcomed / needed.

One final idea though, is to rename this package to ROOTIO.jl, now, technically, this package exists already, however, @peremato has argued using XRootD.jl and Geant4.jl as example that: ROOT.jl and ROOTIO.jl should be the same package, just ROOT.jl. The reason we have ROOTIO.jl right now is that ROOT.jl is too low-level, so ROOTIO.jl is a user-friendly high-level API, but if ROOT.jl APIs are so low-level to the point it's painful to use, then we should include the usable high-level APIs in it, and it will be less confusing for users to navigate package landscape (we can simply say, to use Julia wrapper for ROOT, install ROOT.jl, instead of also pointing them to ROOTIO.jl). We want to know what @grasph thinks about this, of course.

Finally, just to have more people joining the bike shedding party: @oschulz @szabo137 @jstrube

[oschulz]

I like UnROOT. :-)

[jstrube]

For what it's worth, I do agree that the name should be positive, and boring names do help with discovery. If Root.jl or rootio.jl aren't registered, I'd use those, maybe after a courtesy mail to the existing repo owners.
Otherwise, a completely different name? Taro.jl, or gobo.jl or something like that?

[tamasgal]

When I gave this package the name "UnROOT", I was mostly referring to something which is "freed", in the sense that it starts to float in space (unrooted; not tied to a specific place -- framework/language/paradigm; the ents! of you are into LOTR). It was not meant in a negative way toward ROOT but in a positive way towards freedom ;)
I still feel that whenever I import this package 😅
That being said, I'd prefer to keep it as it is. It's part of the (hi)story.

[ianna]

[szabo137]

Just to support Toms's take on this: I never had the impression of negativity, when I heard about UnROOT.jl. I know this is subjective, but for me, it usually sounds like something that gets rid of its immobility, and rootedness and begins to walk/fly/move without being attached to its "roots" (many thanks for the reference the LOTR and the ents, love that!). In some sense, this pays credit to the fundament CERN-ROOT (to not overstress the root metaphor), but at the same time makes clear, that you don't need this fundament anymore (at least not for the features provided).

Maybe one could add a banner to the readme "ROOT without ROOT", or similar, to indicate the friendliness of the project when it comes to its ROOTs (sorry, again).

[oschulz]

I was mostly referring to something which is "freed"

That's how I always understood it, too - accessing ROOT files without ROOT.

[Moelf]

yeah while that certainly is a good interpretation, and also supported by dictionary... I also think it's possible for people to read "un" as "anti or opposite", as in, "unfriend or unplug", especially some might think "unroot" is not an english word (uproot is more commonly used I suppose, and doesn't carry the "un-")

[aoanla]

I mean, I don't particularly think that "some people might not think this is an English word" is a valid objection: we are allowed to make new words even if it wasn't!
I would note that the general sense of "up-" versus "un-" as English language prefixes is that "up-" implies a state resulting from a modification [removing the rootedness of something previously rooted] whilst "un-" generally indicates a lack of the state without necessarily having needed modification [something that is simply not rooted - and may or may not have ever been].

[Moelf]

accessing ROOT files without ROOT.

regardless of if we rename or not, now I think SansROOT.jl would be a good name for example. I think the crux of the issue (which is by no means clear/obvious) is if un- prefix carries negative connotation

[aoanla]

Certainly better than my immediate thought: "ROOTless.jl" ! [Although I guess there's some kind of pun there with less as a commonly known tool for viewing [text] files...]

[jpivarski]

Although it's still negative, I like the idea of a package called "rootless". There was once a package called "lichen" because lichens don't have roots, but I thought the reference was a bit obscure.

https://i.giphy.com/media/v1.Y2lkPTc5MGI3NjExejZpMDEyazlsdXNhdWVhcjhrNTd5MHNqbGJqMzR4Zjc1bGlxMmMyYSZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/76IGroXQrfTQk/giphy.gif

[peremato]

If one uses the naming wisdom of other packages in Julia that access different data formats (e.g. Parquet.jl, HDF5.jl) the package should be called ROOT.jl. But then we have a problem with the wrapper package to ROOT (C++) libraries, which I suggested yesterday that we need to merge the current ROOT.jl (the C++ wrapper) with RootIO.jl (Julia friendly API). What about call it LibROOT.jl?

[8me]

To be clear what I propose is: UnROOT.jl -> ROOT.jl ROOT.jl + RootIO.jl -> LibROOT.jl

That sounds a little bit too much like playing renaming carousel ... :-/

[jpivarski]

UnROOT.jl -> ROOT.jl
ROOT.jl + RootIO.jl -> LibROOT.jl

If you can move these projects without the GitHub redirections being confusing (i.e. issue numbers for the current ROOT.jl project accidentally pointing to unrelated issues in UnROOT.jl), then the above sounds like a good idea. This project should have a central name, since it's what users should find first (like "hist" being more user-level than "boost-histogram").

[jpivarski]

Although ROOT.jl is currently only using up to issue/PR number 26, which would mean only 26 wrongly redirected URLs—maybe not a problem.

[Moelf]

I think ROOT.jl would be better reserved for pyROOT counterpart.

[tamasgal]

Yes, ROOT.jl sounds too "official" to me 😉

[graeme-a-stewart]

Hi, so my contribution to the colour of the bike shed... 🤣

I totally get that the inspiration for the name was not intended to be negative, but it's about perception and clearly for some other reasonable people it does come across that way (un => opposite, not). So I am happy to entertain a name change and now is a good time to do it, before RNTuple v1.0.

I have to say I love the sound of UnROOT in the sense that it's pithy and it just feels nice in the mouth (yeah, this is subjective!). So I would like to keep the same prefix-name structure. I do agree that we should have ROOT as the name, it just makes the intention of the package so much clearer, so it's prefix-ROOT.

So I offer two suggestions:

• ReROOT - To take up and plant again the data, moving from C++ to Julia
• GrROOT - Grafted ROOT data, from C++ to Julia (and it's also a nod to the Groot character, "An extraterrestrial, sentient tree-like creature", which is kind of cute)

I'd be happy with either of those.

[jpivarski]

Just to note: there's already two HEP-related software projects called "groot": one is the JLab Hall B software framework, implemented in Java, and the other is the Go ROOT I/O.

Similarly, "jroot" is Java-ROOT.

[graeme-a-stewart]

Just to say, I'm not worried about confusion between Go's groot and any GrROOT.jl - the name is different (even if homophones) and different languages are sort of like different namespaces! I can't see anyone getting muddled up.

[8me]

I always thought UnROOT stands for: Ultimative native ROOT Tool :D

[tamasgal]

Changing the name of something which has been there for more than four years is in my opinion a big thing and should be driven by strong justification and reflect a meaningful improvement. Changing the name will certainly screw up a couple of things: dependency management, existing scripts, talks, tutorials, docs etc.

If I understood correctly, the main concern is that it might sound negative for some people.

Why is that a concern? Do we fear that people might not use it? That people stay in the ROOT world and miss the opportunity of trying a new way of accessing ROOT files with a modern language?

What exactly is the gain of renaming this package, or let me ask differently: what do we hope to achieve when we rename it?

I cannot support this until I am confident that it brings meaningful improvement. I’ve questioned whether I’m being overly emotional, but I believe my stance is ROOTed in sound reasoning. 😉

[Moelf]

yeah I think this bike shedding is assuming we ignore the technical logistics for a moment -- I think certainly it's not nothing, but at the same time, it's still possible, we don't have O(1000) users yet

[Moelf]

if we want to talk about logistics a second, I mean we won't yank UnROOT -- whatever project depends on it will continue to work, maybe we will archive the repo, and when user installs it from scratch it will throw an error or waning or whatever and redirect to the new package.

But yeah I mostly agree with you we should think about if this brings (enough) meaningful improvement

[jpivarski]

Also, UnROOT is already fairly well known, and there's a danger that changing names will lose them (which @tamasgal pointed out just now and I mentioned yesterday).

But how about this: "UniROOT.jl". By only changing one letter (and properly redirecting in GitHub), you're less likely to lose anybody ("UniROOT is the new UnROOT"). But it also addresses the negativity criticism: "uni" is central, it's the One, like Neo in the Matrix...

[oschulz]

I would recommend to keep ROOT.jl for the wrapper around ROOT, it seems most intuitive to me. If you Pkg add ROOT, you should get the actual ROOT.

[graeme-a-stewart]

I agree - much like Geant4,jl and Pythia8.jl gets you what you expect, wrapped version of the non-Julia code. The contrary is a bit of name piracy 🏴‍☠️ .