[main] rootls: add flag to show RNTuple field hierarchy

[silverweed]

This Pull request:

adds a -R flag to rootls to print RNTuple field trees recursively (similarly to the -t flag for TTree). Fields are sorted by name.

Sample output (cut for brevity):

rootls -R ~/src/iotools/data/gg_data\~zstd.ntuple
ROOT::RNTuple  Dec 18 15:55 2024 mini;1 ""
  SumWeights                 float
  XSection                   float
  channelNumber              std::int32_t
  ditau_m                    float
  eventNumber                std::int32_t
  jet_E                      std::vector<float>
    _0.......................float
  jet_MV2c10                 std::vector<float>
    _0.......................float
  jet_eta                    std::vector<float>
    _0.......................float
  jet_jvt                    std::vector<float>
    _0.......................float
  jet_n                      std::uint32_t
  jet_phi                    std::vector<float>
    _0.......................float
  jet_pt                     std::vector<float>
    _0.......................float
  jet_pt_syst                std::vector<float>
    _0.......................float
  jet_trueflav               std::vector<std::int32_t>
    _0.......................std::int32_t
  jet_truthMatched           std::vector<bool>
    _0.......................bool
  largeRjet_D2               std::vector<float>
    _0.......................float

Checklist:

• tested changes locally
• updated the docs (if necessary)

[enirolf]

For TTree, rootls talks about tree rather than ttree. Do we want to keep this convention and use ntuple instead of rntuple (and with it maybe use -n instead of -R)?

I don't have a strong opinion myself, just want to mention it for consideration!

[silverweed]

use ntuple instead of rntuple (and with it maybe use -n instead of -R)?

A problem I see with that is that technically we have other "ntuple" classes other than RNTuple (like TNTuple), so maybe we want to be extra specific (it's also the name that people who know it know it by so perhaps more familiar and immediately recognizable)

[github-actions]

Test Results

    21 files      21 suites   3d 9h 51m 35s ⏱️
 3 205 tests  3 205 ✅ 0 💤 0 ❌
65 648 runs  65 648 ✅ 0 💤 0 ❌

Results for commit 6da3f1c.

♻️ This comment has been updated with latest results.

[enirolf]

use ntuple instead of rntuple (and with it maybe use -n instead of -R)?

A problem I see with that is that technically we have other "ntuple" classes other than RNTuple (like TNTuple), so maybe we want to be extra specific (it's also the name that people who know it know it by so perhaps more familiar and immediately recognizable)

Yes, that actually also came up in my mind after posting this comment. It's a good reason to keep it like this, then!

[enirolf]

LGTM!

[jblomer]

Nice! I think we should add a roottest for this.

[jblomer]

We already have GetFieldIterable with a comparator parameter. Here would be a use case for this.

[silverweed]

I can use GetFieldIterable() to save a line, yes, but why would I need the comparator?

[pcanal]

(and with it maybe use -n instead of -R)?

Why isn't both -t and -R spelt -r[ecursive]? Why make the distinction between the 2 containers?

[silverweed]

@pcanal -r already has the meaning of "show every object in the hierarchy including subdirectories" (but without expanding them). That's a useful option to have without necessarily expanding all internal structures of trees and rntuples.