Should the GeoSvc implementation live in k4FWCore?
- Dominant language
- C++
- Stars
- 14
- Forks
- 34
- Avg merge
- 2d 23h
- Merged PRs (30d)
- 6
Description
Currently the `GeoSvc` is implemented in `k4SimGeant4`:
- https://github.com/key4hep/k4SimGeant4/blob/main/Detector/DetComponents/src/GeoSvc.h
- https://github.com/key4hep/k4SimGeant4/blob/main/Detector/DetComponents/src/GeoSvc.cpp
However, the `IGeoSvc` interface is defined in `k4FWCore`: https://github.com/key4hep/k4FWCore/blob/main/k4Interface/include/k4Interface/IGeoSvc.h
Should we move the implementation to k4FWCore?
At least for me that was where I would have expected it to be when I first looked for it. A possible disadvantage would be that k4FWCore picks up DD4hep as a dependency, which it doesn't currently have.
Contributor guide
Research direction
Start by reading k4SimGeant4/Detector/DetComponents/src/GeoSvc.h and GeoSvc.cpp alongside k4FWCore/k4Interface/include/k4Interface/IGeoSvc.h. Compare the implementation's dependencies with k4FWCore's current dependency set, especially the possible DD4hep dependency. Done means the maintainers have decided where GeoSvc belongs and recorded the dependency or migration implications.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- backend-api-design
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100