Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TST: fix travis, use conda #47

Closed
wants to merge 6 commits into from
Closed

Conversation

andyfaff
Copy link
Contributor

Currently the travis build is failing. This PR will fix that.

@andyfaff
Copy link
Contributor Author

The first commit allows the travis build to get to the script section. It was failing at a much earlier stage previously.
However, there are failures on the script stage. Before I can fix those I need to understand the directory structure required/desired for build_tools\travis_build.sh. Could someone explain that to me?

AFAIU sasmodels needs to be in a parallel directory to sasview. At the start of the script section the current working directory is TRAVIS_BUILD_DIR. You are in the root folder of the sasview repo at this point.
The first line of the script section exports WORKSPACE. The absolute path that is used can't be relied on. I don't think it's guaranteed that TRAVIS_BUILD_DIR is equal to WORKSPACE/sasview. Perhaps WORKSPACE needs to be TRAVIS_BUILD_DIR/.. and sasmodels should be cloned into that location?

@andyfaff
Copy link
Contributor Author

Further investigation reveals that the script region runs, but only if the travisCI is working off the SasView organisations view of the sasview repository. i.e. andyfaff/sasview fails at a much earlier stage than SasView/sasview. This means that there is something fishy going on with paths.
Furthermore, there appear to 10 errors whilst running the test suite.

@pkienzle
Copy link
Contributor

(1) numpy version on travis is newer, so need to fix sas/sascalc/calculator/slit_length_calculator.py so that ind = 0 rather than ind = 0.0.

(2) matplotlib is complaining that pyparsing isn't > 1.5.6. Since miniconda is installing matplotlib it seems that this is a problem with miniconda.

(3) There are numerous errors with the data loader that don't occur when I run tests from my local install. These may have been fixed. Make sure your fork is up to date with master.

(4) Long term, the travis build system should mirror the ESS linux build system for the linux distribution. Put the scripts to set up the Ubuntu build environment inside the repo itself and have travis run that.

(5) There is a separate question of whether the test system should use the latest anaconda version (since that's what new developers will see) or if it should be fixed at a particular version.

(6) travis isn't recognizing that the doc build is partly failing because bumps isn't installed where it is expecting it (part of the docs are pulled in from the bumps repo). Line 2277 of the travis output.

(7) building docs requires importing gui modules which requires wx which is not part of the miniconda package list. Line 2370 of the travis output.

(8) similarly docs requires py2exe (line 3533). Fixing this will require restructuring the tree to separate the build system files from the packaging. I did this in my own fork before the last code camp: https://github.com/pkienzle/sasview; it is probably worth doing after the 4.1 release. I created ticket #887 for this.

@andyfaff
Copy link
Contributor Author

andyfaff commented Mar 21, 2017 via email

@pkienzle
Copy link
Contributor

Re: (1), the author of the code is no longer on the project; no one is particularly familiar with it.

Re: (3), please turn on the actual test step so I can see how it is failing again

Re: (8), building the docs isn't causing travis to complain; leave it in for now so that we can still see the build output.

I'm not sure how miniconda is interacting with system packages. I would be tempted to go with apt packages all the way (except pyopencl) since that's how I'm running on my version of ubuntu.

@pkienzle
Copy link
Contributor

(3) failing readers may be due to floating point indexing into numpy arrays in the IGOR reader. This is moved to ticket #888, which won't be addressed until 4.2. I'm going to close this merge request for now, and you can reopen it when #888 is addressed.

@pkienzle pkienzle closed this Mar 21, 2017
@andyfaff
Copy link
Contributor Author

andyfaff commented Mar 21, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants