pin-it just for testing
most conda-forge packages include source code and built
in this case this is just an meta package - could distribute env other ways, but this is a way to make sure it is solveable
meta.yaml most straightforward. package build and req part, lumps all req under "run" since there is no build test phase here since it's a meta pacakge.
the nosysroot - was because Matt wanted to used it for stackvana and he wants that to run even on older Centos sysroot, but we don't guarenntee - we pin sysroot. We may not need that. Put nosysroot.
fading away - since conda-forge due to changes in conda-forge
build script - copy activates and deactivate scripts are just setting up the eups stuff
we overwrite eups path in their tools like lsstw - may not always piotn to the eups in the conda env, but it'sa safe default.
LSST adds stuff at NCSA - can conda install on top. In some cases not in conda and can pip install on top.
pip install --user happens, we tend to suggest and cloning instead. working out , mostly happens in RSP - we have checkbox on to reurn to defalt
conda-forge - still working out, how to version and keep it updated
different packages have different versioning schemes, sometime
which kind of inequalities in versiioning. If theproblem looks like upstream proglem, then we should use != so we don't have to issue new
after or before that can be used, then the , and have an idea if the prblem is really upstream, vs if we have to change our code to fix it.
< or ==
eups.lsst.codes along wih manifest file has in it a ptr to a label for the env that was used. We upload list explicit file in a special taht isn't known to eups but is also on eups.lsst.codes, so in the saem place. Our isntall tooling can optipnally look up the label and fidn theexplict list and build the env rather meta package
store it where ever you
we already -
Jenkins builds because there is x-repo support. building the whole stack on GH actions
builds are using groovy scripts that call lsstw which call lsst-build and clones everything, checks out the refs in each repo and then goes thru and builds via "eups pkg" Building taballs "eups distrib create" Jenkins builds the docker containers and does verification test. docker layers, new istnall layer which is lsst/lsst triggers builds, if we do want to capture new rubin-env and I can manually trigger. newinstall Containes all of the conda env in it. Another docker file that builds all of eups distrib all tarballs on top and then cleans things – then RSP is built on top of that.
Singularity