Remove dependency on dfelibs #893
Conversation
The ACTS project is deprecating its fork of dfelibs, which we use only for CSV reading. Thus, this commit removes our dependency on dfelibs and simply places the relevant code into the traccc repository.
|
|
Is that GH repository actually going to be removed? 🤔 If not, I would not bother with this here. I see nothing to be gained from making this change. Not on a repository that has a finite lifetime of its own. Is Acts still going to continue to use this code for its own CSV I/O? If so, we'll just pick it up from Acts's codebase when we migrate the components of this repository into the Acts one. But if Acts is switching to a different technology, then we'd of course need to switch to that different technology here a priori as well. But that's not what's happening from what I understand, right? |
|
Not to mention that if Acts already has its own copy of that code, then we're at option C. We should be picking up the DFE code from Acts ourselves as well, once we switch to "that" version of Acts. Otherwise we could get into all sorts of issues with diverging codebases. However I look at it, making a copy of the code into this repository does not seem to be the correct choice in any circumstance. 🤔 |
|
Sure let me see if I can pick up the ACTS header instead... |
|
Ah no that lives in ActsExamples |
In that case I'm back to option A. 🤔 Is there anything to be gained with putting effort into this right now? Our build literally just needs an old TGZ file, which hopefully doesn't go away for a while longer. |
The ACTS project is deprecating its fork of dfelibs, which we use only for CSV reading. Thus, this commit removes our dependency on dfelibs and simply places the relevant code into the traccc repository.