Closed danielsf closed 8 years ago
@mareuter did not have this problem on OSX, though he did have it on Linux.
The difference between his OSX and mine is that he is running El Capitan and I am still running Yosemite. I am still too scared to update my principal computer to El Capitan. I will try this on my older laptop, running El Capitan, when I get home tonight.
Looking at the scons list
output, looks like scons is declared twice, once from the lsst-scons
package, and once with the version system
:
scons 2.3.5 conda b1923
scons system current
I wonder if this has something to do with stopping to use conda-bundled scons, and switching to our scons (has it been removed from legacy_configs
)? @jhoblitt, any ideas?
Uh, err, umm... the PR to legacy_configs
https://github.com/mjuric/legacy_configs/pull/2 needs to be merged.
I've merged it but we probably need to make a tag and update config.yaml
Uh, err, umm... the PR to legacy_configs mjuric/legacy_configs#2 needs to be merged.
:p. oops.
I've merged it but we probably need to make a tag and update config.yaml
Probably (I know you're swamped -- maybe @danielsf can help?)
Sure. I'll see what I can do.
how do I force conda-lsst to update lsst-product-configs? It insists that lsst-product-configs is up-to-date, despite the change in legacy_configs
It needs to be tagged. I'm out at lunch but if you can sit tight for a couple of hours I will be able to take care of it.
Thanks.
For future reference, can you document what you are doing so that I can handle this in the future? I get the sense that legacy_configs.git needs a tag, but the only tag I currently see there is 1.0.0 and lsst-product-configs says it is on version 0.0.1, so I am confused.
Again, thanks.
I will skim the README and see if anything is missing. Most of my work was from b1881 and we're on b1925 -- I'm suspicious that there won't have been breakages. I've started a build of b1925 to see how far it gets. I'm planning to cut a tag along the lines of 1.0.1925
if its in a working state.
@danielsf @jhoblitt Josh brings up a good point -- conda-lsst
is almost by definition a moving target, wrt. applying it to arbitrary bNNNN builds. Given it has things such as package overrides, patches, etc., it should always work on the latest ones, but it's not guaranteed to work on the older bNNNN builds; e.g., a change in a patch that's being applied will break the old builds. To ensure reproducible builds, you should really save the generated recipes. That's why conda-lsst
doesn't do a build itself, but generates the recipes (and the convenience rebuild.sh
file).
If you have to generate recipes for an older release, you'd probably want to check out a commit of conda-lsst
that is close in time to it. I'm thinking it may be a good (informal) practice to start tagging conda-lsst with bNNNN tags, whenever we use it to build one, to know which commit worked?
A long(er) term solution is potentially to split up the contents of the etc/
directory (patches, package overrides, etc) from the recipe generator (the rest of the code). They're now less coupled than they used to be. I'm not sure if it's worth it, though (I change my mind on that three times a day...).
I've made an update to legacy_configs
and tagged it as 1.0.1925
-- but already suspect I should have used the minor version to reflect the build #. With this PR https://github.com/mjuric/conda-lsst/pull/48, I am able to build all of lsst_distrib
and qserv_distrib
but run into trouble with sims_utils
tests failing with ConfigurationMissingWarning: Configuration defaults will be used due to OSError:Could not find unix home directory to search for astropy config dir on None
.
@jhoblitt What machine are you running this build on. We saw this failure on Jenkins once. It was (I think) literally because the environment variable $HOME was meaningless. I thought we had commented all of the offending tests out.
@danielsf Centos 5. This is the container I've been doing all conda-lsst related work in:
docker run -ti lsstsqre/centos:5-conda-base bash
@danielsf The astropy error appears to be coming from https://github.com/astropy/astropy/blob/master/astropy/config/paths.py#L47-L48 -- I'm wondering if scons is santizing away HOME. Can you look into this?
@danielsf Actually, I wasn't being very cleaver and looking at the entire backtrace. (The warning message from astropy was a red herring)The problem is obvious:
tests/test_samplingFunctions.py
/home/conda/conda-lsst/miniconda/envs/_build/lib/python2.7/site-packages/astropy/config/configuration.py:687: ConfigurationMissingWarning: Configuration defaults will be used due to OSError:Could not find unix home directory to search for astropy config dir on None
warn(ConfigurationMissingWarning(msg))
Traceback (most recent call last):
File "tests/test_samplingFunctions.py", line 18, in <module>
from lsst.sims.utils import ObservationMetaData
File "/home/conda/conda-lsst/miniconda/conda-bld/work/python/lsst/sims/utils/__init__.py", line 12, in <module>
from .healpyUtils import *
File "/home/conda/conda-lsst/miniconda/conda-bld/work/python/lsst/sims/utils/healpyUtils.py", line 2, in <module>
import healpy as hp
File "/home/conda/conda-lsst/miniconda/envs/_build/opt/lsst/healpy/lib/python/healpy-1.8.1-py2.7-linux-x86_64.egg/healpy/__init__.py", line 47, in <module>
from .sphtfunc import (anafast, map2alm,
File "/home/conda/conda-lsst/miniconda/envs/_build/opt/lsst/healpy/lib/python/healpy-1.8.1-py2.7-linux-x86_64.egg/healpy/sphtfunc.py", line 22, in <module>
import six
ImportError: No module named six
Well, that's "good"
I started down this rabbit hole because I couldn't get healpy to import 'six' in the latest version of the sims stack. I suspect it just needs to be added to the list of packages to be conda installed. I will open a branch and see if I can fix this.
That works but adding it to healpy is a better solution (what I've done). However, I've run into another problem I haven't tracked down yet.
@danielsf I can't get past sims_photUtils
, which I am speculating is trying to load data from an LFS repo but I haven't investigated.
Failed test output:
tests/testPhotometry.py
/home/conda/conda-lsst/miniconda/envs/_build/lib/python2.7/site-packages/astropy/config/configuration.py:687: ConfigurationMissingWarning: Configuration defaults will be used due to OSError:Could not find unix home directory to search for astropy config dir on None
warn(ConfigurationMissingWarning(msg))
.E.
======================================================================
ERROR: testEBV (__main__.photometryUnitTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "tests/testPhotometry.py", line 100, in testEBV
ebvOutput = ebvObject.calculateEbv(equatorialCoordinates=equatorialCoordinates)
File "/home/conda/conda-lsst/miniconda/conda-bld/work/python/lsst/sims/photUtils/EBV.py", line 261, in calculateEbv
self.load_ebvMapNorth()
File "/home/conda/conda-lsst/miniconda/conda-bld/work/python/lsst/sims/photUtils/EBV.py", line 214, in load_ebvMapNorth
self.ebvMapNorth.readMapFits(os.path.join(self.ebvDataDir,self.ebvMapNorthName))
File "/home/conda/conda-lsst/miniconda/conda-bld/work/python/lsst/sims/photUtils/EBV.py", line 27, in readMapFits
hdulist = pyfits.open(fileName)
File "/home/conda/conda-lsst/miniconda/envs/_build/opt/lsst/pyfits/lib/python/pyfits-3.4-py2.7-linux-x86_64.egg/pyfits/hdu/hdulist.py", line 124, in fitsopen
return HDUList.fromfile(name, mode, memmap, save_backup, **kwargs)
File "/home/conda/conda-lsst/miniconda/envs/_build/opt/lsst/pyfits/lib/python/pyfits-3.4-py2.7-linux-x86_64.egg/pyfits/hdu/hdulist.py", line 266, in fromfile
save_backup=save_backup, **kwargs)
File "/home/conda/conda-lsst/miniconda/envs/_build/opt/lsst/pyfits/lib/python/pyfits-3.4-py2.7-linux-x86_64.egg/pyfits/hdu/hdulist.py", line 823, in _readfrom
hdu = _BaseHDU.readfrom(ffo, **kwargs)
File "/home/conda/conda-lsst/miniconda/envs/_build/opt/lsst/pyfits/lib/python/pyfits-3.4-py2.7-linux-x86_64.egg/pyfits/hdu/base.py", line 370, in readfrom
**kwargs)
File "/home/conda/conda-lsst/miniconda/envs/_build/opt/lsst/pyfits/lib/python/pyfits-3.4-py2.7-linux-x86_64.egg/pyfits/hdu/base.py", line 430, in _readfrom_internal
header = Header.fromfile(data, endcard=not ignore_missing_end)
File "/home/conda/conda-lsst/miniconda/envs/_build/opt/lsst/pyfits/lib/python/pyfits-3.4-py2.7-linux-x86_64.egg/pyfits/header.py", line 423, in fromfile
padding)[1]
File "/home/conda/conda-lsst/miniconda/envs/_build/opt/lsst/pyfits/lib/python/pyfits-3.4-py2.7-linux-x86_64.egg/pyfits/header.py", line 492, in _from_blocks
raise IOError('Header missing END card.')
IOError: Header missing END card.
----------------------------------------------------------------------
Ran 3 tests in 0.367s
FAILED (errors=1)
Yes, the data that testEBV is trying to load is indeed from a gitlfs repo -- sims_maps -- and your error is entirely consistent with trying to use the pointers in the git repo (instead of the data from git LFS). I believe Scott found that you could just try building against a repo properly downloaded with git LFS.
On Thu, Feb 18, 2016, 4:07 PM Joshua Hoblitt notifications@github.com wrote:
@danielsf https://github.com/danielsf I can't get past sims_photUtils, which I am speculating is trying to load data from an LFS repo but I haven't investigated.
Failed test output: tests/testPhotometry.py
/home/conda/conda-lsst/miniconda/envs/_build/lib/python2.7/site-packages/astropy/config/configuration.py:687: ConfigurationMissingWarning: Configuration defaults will be used due to OSError:Could not find unix home directory to search for astropy config dir on None warn(ConfigurationMissingWarning(msg))
.E.
ERROR: testEBV (main.photometryUnitTest)
Traceback (most recent call last): File "tests/testPhotometry.py", line 100, in testEBV ebvOutput = ebvObject.calculateEbv(equatorialCoordinates=equatorialCoordinates) File "/home/conda/conda-lsst/miniconda/conda-bld/work/python/lsst/sims/photUtils/EBV.py", line 261, in calculateEbv self.load_ebvMapNorth() File "/home/conda/conda-lsst/miniconda/conda-bld/work/python/lsst/sims/photUtils/EBV.py", line 214, in load_ebvMapNorth self.ebvMapNorth.readMapFits(os.path.join(self.ebvDataDir,self.ebvMapNorthName)) File "/home/conda/conda-lsst/miniconda/conda-bld/work/python/lsst/sims/photUtils/EBV.py", line 27, in readMapFits hdulist = pyfits.open(fileName) File "/home/conda/conda-lsst/miniconda/envs/_build/opt/lsst/pyfits/lib/python/pyfits-3.4-py2.7-linux-x86_64.egg/pyfits/hdu/hdulist.py", line 124, in fitsopen return HDUList.fromfile(name, mode, memmap, save_backup, _kwargs) File "/home/conda/conda-lsst/miniconda/envs/_build/opt/lsst/pyfits/lib/python/pyfits-3.4-py2.7-linux-x86_64.egg/pyfits/hdu/hdulist.py", line 266, in fromfile save_backup=save_backup, _kwargs) File "/home/conda/conda-lsst/miniconda/envs/_build/opt/lsst/pyfits/lib/python/pyfits-3.4-py2.7-linux-x86_64.egg/pyfits/hdu/hdulist.py", line 823, in _readfrom hdu = _BaseHDU.readfrom(ffo, _kwargs) File "/home/conda/conda-lsst/miniconda/envs/_build/opt/lsst/pyfits/lib/python/pyfits-3.4-py2.7-linux-x86_64.egg/pyfits/hdu/base.py", line 370, in readfrom _kwargs) File "/home/conda/conda-lsst/miniconda/envs/_build/opt/lsst/pyfits/lib/python/pyfits-3.4-py2.7-linux-x86_64.egg/pyfits/hdu/base.py", line 430, in _readfrom_internal header = Header.fromfile(data, endcard=not ignore_missing_end) File "/home/conda/conda-lsst/miniconda/envs/_build/opt/lsst/pyfits/lib/python/pyfits-3.4-py2.7-linux-x86_64.egg/pyfits/header.py", line 423, in fromfile padding)[1] File "/home/conda/conda-lsst/miniconda/envs/_build/opt/lsst/pyfits/lib/python/pyfits-3.4-py2.7-linux-x86_64.egg/pyfits/header.py", line 492, in _from_blocks raise IOError('Header missing END card.') IOError: Header missing END card.
Ran 3 tests in 0.367s
FAILED (errors=1)
— Reply to this email directly or view it on GitHub https://github.com/mjuric/conda-lsst/issues/47#issuecomment-185987311.
@rhiannonlynne I suspected as much. This means building conda packages for sims is essentially blocked until LFS support is added to conda-lsst. I don't believe that will be very difficult -- just need to find the time.
@danielsf didn't you release sims2.2.2 in conda? And that has sims_maps as a dependency? Or am I just confused? (I haven't followed which version is actually available as closely as I might have..)
On Thu, Feb 18, 2016, 4:19 PM Joshua Hoblitt notifications@github.com wrote:
@rhiannonlynne https://github.com/rhiannonlynne I suspected as much. This means building conda packages for sims is essentially blocked until LFS support is added to conda-lsst. I don't believe that will be very difficult -- just need to find the time.
— Reply to this email directly or view it on GitHub https://github.com/mjuric/conda-lsst/issues/47#issuecomment-185989885.
@rhiannonlynne I released sims_2.2.2 through eups. Other things (which, I guess, @jhoblitt has now fixed -- thanks!) prevented me from releasing it through conda. I was not sure whether conda could handle git lfs. I guess we know the answer now.
EUPS cant handle git-lfs either, so I'm confused how it could work in EUPS and not in conda?
I talked with KT about this.
As long as you publish your package with
EUPSPKG_SOURCE=git publich -b bNNNN -t tag package_name
eups distrib install will be able to handle LFS (assuming the user has LFS installed on their machine).
"publich" = "publish"
There has been some debate as how to handle eups distrib publishing of lfs packages. I think people are leaning towards some sort of annotation on the lfs repos to force them to be published as a git
package rather than distributing multi-gigabyte packages.
I think it's a mistake to package these as EUPS products at all; they're really datasets, not versioned pieces of code. IMHO, they should live in repositories (butlerized, ultimately, though currently backed by git(-lfs)). It'd be good to get @ktlim's angle on this.
@danielsf @rhiannonlynne -- is there a reason not to have sims_maps
be something the users clone themselves (maybe with some convenience scripts or APIs that would make that easy, or even fully automated)? I guess git-lfs
itself would serve just that purpose (if we reinterpret the sims_maps
package as "the code that fetches the maps dataset, which happens to be using git-lfs right now").
I think people are leaning towards some sort of annotation on the lfs repos to force them to be published as a git package rather than distributing multi-gigabyte packages.
You should be able to just say SOURCE=git
in eupspkg.cfg.sh
to force it (haven't tested it).
@mjuric I don't think I have any strong opinion on whether or not users should clone sims_maps themselves, except to say that we should make it as easy as possible. The instructions for setting up git-lfs are a little cumbersome, being a multi-step process even for anonymous access (http://developer.lsst.io/en/latest/tools/git_lfs.html). Making users then have to install the LSST stack, and also download sims_maps separately seems awkward (and I guess we'd have to require people to install sims_maps first, so that the packages would install and test correctly?).
I'd love to see this whole thing get easier and ideally be invisible (almost invisible?) within the process of installing the LSST stack.
Agreed on the desire for the ease of use. @jhoblitt has been working on a conda package for git-lfs
; that (in combination with SOURCE=git
) may make the whole thing fully transparent.
But in the long run delivering repositories as EUPS products doesn't seem right...
I think we would like to support some degree of versioning on these packages. For example: sims_sed_library is the next candidate for upgrade to git-lfs. This package contains simulated SEDs for different classes of stars and galaxies. We would like to be able to change models as new models become available, but easily revert to previous models should we need to recreate old results.
Support is going into the Data Butler to be able to handle versions of repositories (but versions exposed as git versions may be a bit of a challenge), if you can hold out a month or two.
@danielsf This should be resolved as of the b1925
tag. However, I am battling new issues with b1935
.
Thanks. It's all moot for me since conda cannot handle LFS (my principal interest in conda-lsst is for producing builds of lsst_sims, which now relies on LFS repositories)
FYI - I have a working git-lfs recipe https://github.com/mjuric/conda-lsst/pull/49 but haven't started on adding lfs support logic to conda-lsst.
Thanks for doing all of this, @jhoblitt
Builds of sconsUtils are failing. I cannot determine why based on the resulting
_build.log
file. The specific command I tried wasconda lsst make-recipes build:b1923 sconsUtils --build
The resulting build log is