Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the +rootio dependency for hepmc3 #611

Merged
merged 4 commits into from
Jul 8, 2024
Merged

Remove the +rootio dependency for hepmc3 #611

merged 4 commits into from
Jul 8, 2024

Conversation

jmcarcell
Copy link
Member

See #608. The issue here is that dual-readout requires hepmc3 with +rootio and that makes it depend on ROOT. However, ROOT depends on pythia8 who depends on hepmc3 by default, creating a cycle that spack silently breaks by not requiring hepmc3 with pythia8.

@jmcarcell
Copy link
Member Author

jmcarcell commented Jul 8, 2024

I think the hepmc3 dependency can be dropped in dual-readout; the only occurrence that I could find was https://github.com/HEP-FCC/dual-readout/blob/master/DRsim/DRsimG4Components/test/runDRsim.py#L28 and that doesn't need it to depend on hepmc3. Other dependencies can be simplified or simply removed too.

@jmcarcell jmcarcell merged commit 8f75234 into main Jul 8, 2024
5 checks passed
@jmcarcell jmcarcell deleted the pythia8-hepmc3 branch July 8, 2024 15:26
@tmadlener
Copy link
Contributor

HepMCToEDMConverter seems to be from k4Gen, so as long as dual-readout depends on k4Gen (runtime only?), things should work in this PR.

I am not sure why spack has to break a cycle here. pythia8 +hepmc3 is the default (see package.py). None of the packages seem to bring in any additional requirements in their depends_on statements. Additionally, hepmc and hepmc3 can be active at the same time in pythia8 (or at least there is no conflict that says otherwise). In the end pythia8 +hepmc3 should be a valid solution for the concretizer. Either I am (still) not understanding how the concretizer works, or this is a concretizer bug.

@jmcarcell
Copy link
Member Author

jmcarcell commented Jul 8, 2024

Hmm yes I'll add a dependency on k4Gen.

The cycle is (was), with the arrow meaning depends on:

ROOT -> pythia8 -> hepmc3
   dual-readout -> hepmc3+rootio -> ROOT

Impossible to satisfy with a single version of hepmc3.

@tmadlener
Copy link
Contributor

Aah, OK. Now I get it. Still not sure if it's a concretizer bug or not 😅

@jmcarcell
Copy link
Member Author

I think it's working as expected, variants were never a strong requirement so without require the concretizer has been always able to change them which is what was happening here; when using require it complains and it doesn't concretize because it's impossible to solve. If the concretizer should say something about the variants that it's changing instead of silently changing them that is another question 😃 We learn that if we want a variant it is better to have it explicitly and that it's not good to request dependencies and variants that aren't needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants