search

slaclab / anarel-manage

Manage the conda based analysis release environments that include psana at LCLS.
Other
3 stars 3 forks source link

Breaking up psana #33

Open davidslac opened 7 years ago

davidslac commented 7 years ago

Right now psana-conda is one big package with lots of stuff. This causes problems, one is for - developing pdsdata, you end up having two copies of pdsdata around, the old one, and the one you are developing. Developing pdsdata should look like

conda create --name ddl-conda psddl
github clone lcls-psana/psddldata
svn checkout pdsdata
...

That is you just create a lightweight environment with the ddl compiler, that's all you need as a DAQ developer, you don't need a big conda environment with another copy of pdsdata hiding in it, as well as another copy of psddldata.

So, a plan for breaking up psana-conda

  1. SConsTools gets its own package, and it knows how to install small things into conda environments - now we can split off any other package in the ana build system and create a recipe that installs it in a conda environment
  2. psddl gets its own package
  3. psddldata might not be a conda package, it is something we checkout to make psana
  4. Split off Translator, get static openmpi link dependency out - right now psana-conda run dependencies don't specify which openmpi, but this means the Translator won't run if one uses mpich
  5. I'd be for a 'core' psana - all the code to parse XTC files and create events, one package
  6. Then more algorithmic stuff
  7. Of course split of things like psmon and psgeom that just use psana, but maybe figure out what that core package is and if psmon etc can just depend on that?