C++ interface to read simple TTrees

[andriish]

Dear uproot authors,

would you consider adding a simple C++ interface to uproot, so it would be possible to read ROOT files from C++ using only python (CPython)+ uproot? This could be useful for very simple plain trees.

Best regards,

Andrii

[jpivarski]

The right solution depends on your motivation:

• Is it about ease of use? If so, RDataFrame makes it easy to access simple TTrees (and more complex ones, but especially the simple ones).
• Are you looking for a way to get the data in arrays, rather than one entry at a time? As arrays, what would be your preference: std::vector, std::shared_ptr<void>, ROOT::RVec, ...?
• Is it about speed of deserialization? If so, this would argue for ROOT to provide an interface for the BulkIO deserialization methods that are already implemented.
• is it about dependencies? Is there an advantage to having CPython as a dependency, rather than ROOT? If so, why? (CPython is pretty big, too.) Is it about being able to embed it in an executable or library statically, to avoid version conflicts? Or are you planning to dynamically link to libpython, with the assumption that it's available everywhere?

Just trying to understand the request. Thanks!

[DraTeots]

Is there an advantage to having CPython as a dependency, rather than ROOT? If so, why?

Actually there are advantages:

1. Python is provided for every system. Most of the time it is just as easy as apt install python3-devel to have it ready (and conda comes with headers). Root is not.

2. Even if you need to build your own python, my experience as a package maintainer with python is very good - it just builds and installs most of the time. Root is not. Countless hours where spent by HENP community on fixing failing ROOT builds

3. Python has thorough unit testing and pretty careful API migration, so when you build your app against python the API behaves sane most of the time. Root is not. Spectacular C++17 headers behaviour in recent version (where you have to build your application with the C++ standard as root). And countless number errors and crashes (e.g. classics - crash on app exit because of some destructor, because weird memory cache being dumped into the file. Or crashes because improper termination of QT (!) stuff).

4. Python installation is relatively small and there are projects like micro-python. Root is not. You have to install all or nothing. "Slim" root installation is still 600mb minimum. For certain devices it is crucial. For container creation it might be relevant.

So I would agree that having a c++ that runs python to read/write root files via uproot looks bizarre. But we live in a world where this way actually have advantages over just using ROOT.

[andriish]

Hi @jpivarski ,

I think that might be useful because of the dependencies. ROOT has too many dependencies which can be properly satisfied only on some systems (RH). That makes some people (not me) allergic to ROOT. Having an option to do simple I/O with a much smaller Python runtime could make things easier.

Is it about being able to embed it in an executable or library statically, to avoid version conflicts? Or are you planning to dynamically link to libpython, with the assumption that it's available everywhere?

Oh, that is an interesting option. I haven't thought about it, but it could be interesting.
In any case, this is not a feature request. I just looked at the option of I/O via uproot into C++ for one specific case and that worked quite straightforward for me. So I thought it could be interesting for other people.

Best regards and thanks a lot for uproot,

Andrii

Other questions:

Is it about ease of use?

ROOT works well for me.

Are you looking for a way

I've tried to do things completely w/o ROOT so used just std::vector.

Is it about speed of deserialization

No, just reading ROOT files w/o ROOT.

[andriish]

Hi @jpivarski ,
as that is "idea" not a "feature request"/"question"/etc, I think that makes sense to close it as soon as you find it appropriate.

Best regards,

Andrii

[jpivarski]

I think this can remain open, since "Discussions" are not to-do items like "Issues."

Actually, it looks like the GitHub interface doesn't have a "close Discussion," so it's a moot point. That's good anyway. I want the Discussions to remain open for future reference and updates. (When these things are discussed in Issues, it's somewhat harder to find them after they've been closed, but I need to close completed Issues or I'll have trouble keeping track of what's left to do.)