As the ROOT feedstock is not being rerendered as the conda-forge global pins advance it is also causing downstream breakage on any feedstock that has root_base as a requirement.
and it additionally keeps any new packages from being added to conda-forge that have a ROOT requirement (like CMS Combine — cc Nick Smith).
Is there a plan to support ROOT on conda-forge in the future? It would be more beneficial for people using conda-forge for work to know if ROOT is viable supported in that ecosystem or not, and if not (which could be a very reasonable decision by the ROOT team) it would be better to make this clear then to let the feedstock exist as unmaintained and broken.
Opinion: I’ll also note, as an avid user and maintainer of Linux container images for multiple projects and orgs, that providing support for ROOT on conda-forge would probably have a significantly bigger impact than providing only Linux container images.
I relaxed some dependencies of the GitHub - hep-forge/root-feedstock and simplified the overall structure (in particular about root_base and x11 compatibilities).
While this approach may not be optimal for enabling all features, it has been working quite well for my use cases in combination of other packages.
Currently, the main limitation I faced about ROOT 6.34.02 was about the custom clang patch required. Any input, suggestions, or improvements that might help address this or further enhance the packages are very welcome.
The importance of the conda-forge feedstock is evident, as you say this is not only directly used to install ROOT in a Python environment but it is also a dependency of downstream packages. The ROOT project is making an effort in reprioritising the support for distribution channels, and the conda-forge repository will definitely get more care and attention in the future. This has also been explicitly mentioned in the public presentation of the project plan of work Special SFT Group Meeting - Plans Of Work 2025 (22 January 2025) · Indico.
This is excellent to hear, and thank you for linking to @Danilo’s presentation (I had not seen that yet). Seeing
Make all 6.3X releases available on Conda (continuous)
as a Priority 1 item is exceptional, so that’s great to see the ROOT Team’s plans here.
Perhaps some practical questions: The ROOT Team gets a lot done, though the 22 people of the core team on Slide 31 are also not all working at 1.0 FTE on ROOT, and even then the code and support surface areas the team need to cover are impressively large, given how much ROOT touches / how many users ROOT has. Conda-forge has always emphasized the community aspects of maintenance. When it comes to helping to ensure that conda-forge has stable multi-platform releases of root_base and root, what are the ROOT Team’s requests from the broader physics community for contributions to support this work? Without volunteering anyone, would contributions to the conda-forge feedstock be most valuable? Or would “upstream” contributions to improvements in the build system be more valuable from the team’s perspective? Or something else entirely?
(Sorry for the slow reply — I somehow missed the notification.)
Thanks for the reply and don’t worry about the missed notification.
ROOT adopts an open approach, relying on the three pillars of open-planning (as one can see at the PoW link and related talks ), open-source and open-development model (reviewed PRs for core-devs as well as contributors, symmetrically).
This model is also an expression of how much we value input and contributions from the community, and it pays off in terms of development capacity and rate at which demands of the community are addressed.
In the case of Conda, help from the community would be particularly welcome. In our experience, contributions to the feedstock not seldom required some sort of upstreaming into the build system, also to optimise the effort available focussing maintenance in one place. I don’t know if it’s necessary to be very perscriptive in terms of requests to the broader (physics) community for contributions to support this work; if I had to express one, I would say that any proposed change to the build system should be cautious and well thought, since that component is a pillar of the stability of ROOT, and that is one of the strategic goals of the project.
), open-source and open-development model (reviewed PRs for core-devs as well as contributors, symmetrically).