stackvana-core
core build tooling for stackvana
DISCLAIMER: This installation of the DM stack is not supported, promised to work, or promised to be bug free in any way. You use this package at your own risk.
Usage
It is best to create a brand new conda
environment for the DM stack.
conda create -c stackvana -n mystack stackvana-core
conda create -c stackvana -n mystack stackvana-afw
The command above will create a conda
environment with all of the dependencies
and tools you need to actually build the DM stack. In general, you should consult
the LSST DM
documentation
for details on how to build the DM stack using eups
. This package has
the eups
installation already run up to installing sconsUtils
in order to make
downstream builds easier.
conda
and eups
Integration
Notes on -
The builds are configured to use the compilers provided by
conda
. On linux, these are the GNU compilers. On OSX, these are a combination of the LLVMclang
compilers and the GNU fortran compiler. -
This
conda
package has been carefully constructed to activateeups
(via sourcing${EUPS_DIR}/bin/setups.sh
) and set the needed environment variables to enableeups
to build packages against theconda
environment. This activation happens when theconda
environment is activated. -
Similarly, when the
conda
environment is deactivated, all of the changes made by this package, and those made by activatingeups
, are removed, leaving the original environment intact. -
The
eups
installation in this environment is not completely isolated from the outside world. Globaleups
configuration and caching done in your~/.eups
directory is still visible to all environments. There also appears to be issues witheups
touching the cachedconda
package outside of the installed version in your environment. -
The
$EUPS_PKGROOT
environment variable is set to enable only source builds.
Things that I did that don't make me feel like a good person
-
I have disabled
eups
's locking mechanism to help multiple processes simultaneously use the sameconda
environment with this package. According to Robert Lupton, this choice should be fine. However, as usual with allconda
environments, do not install packages viaconda
oreups
into an environment while running code is using that same environment. Many thanks to Robert Lupton for pointing out how to do modify this configuration option elegantly! -
I changed the first line,
#!${PREFIX}/bin/python
, in theeups
andeups_setup
scripts to#!/usr/bin/env python
. This doesn't seem to make a difference and the CI services that build the stack were failing on the long prefixes used byconda-build
. -
I applied a patch to the
${EUPS_DIR}/lib/eupspkg.sh
script so that it uses old-styledistutils
installs. (I added--single-version-externally-managed --record record.txt
toPYSETUP_INSTALL_OPTIONS
with a fallback to the old way of doing things if these command switches are not accepted.) This change appears to helpsetuptools
find dependencies installed byconda
and appears to help prevent the downloading of dependencies fromPyPi
. Instead, you must install the appropriate package usingconda
.setuptools
should have been able to detect the dependencies in theconda
environment in the first place, but sometimes this was failing for some reason unknown to me.