search

key4hep / key4hep-spack

A Spack recipe repository of Key4hep software.
10 stars 23 forks source link

Remove the +rootio dependency for hepmc3 #611

Closed jmcarcell closed 3 months ago

jmcarcell commented 3 months ago

See https://github.com/key4hep/key4hep-spack/issues/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 commented 3 months ago

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.

tmadlener commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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

jmcarcell commented 3 months ago

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 :smiley: 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.