Travis CI Integration

[eric-tramel]

It would be nice to go ahead and integrate the project into Travis CI. There isn't a huge need at the moment, but it would be nice to already have the configuration completed so we can keep up with the build status and test code coverage as we go forward.

I'm mostly leaving this as a personal to-do, it should take about 20 minutes or less to configure.

[ThomasA]

I am personally a big fan of the Anaconda Python distribution due to its many scientific computing-oriented packages and great package manager which IMO is much better for getting the necessary requirements in place than Travis' standard Python set-up. If you need it, I have Travis config using miniconda from a private project I can share.

[eric-tramel]

@ThomasA Thanks so much for this info! Certainly, if you have some scripts in place to help us along here, it would be great. I haven't used Travis for Python, yet, so I was hoping to learn a bit, but it sounds like you already have the experience on this topic. Do you think you link us your config and describe its difference from the norma Travis set-up?

[ThomasA]

I have just added the example '.travis.yml' file on the new 'travis_setup' branch in https://github.com/GAMPTeam/vampyre/blob/travis_setup/.travis.yml

[ThomasA]

It needs adjustment to fit the current project:

• For less confusion MAGNI_CONDA should be changed to something else - VAMPYRE_CONDA? Line 20 etc.
• Choices should be made about the build matrix (which versions to test in), line 19.
• Paths and filenames need changing to fit the vampyre project. So far I have spotted lines 18, 88, and 91.
• Required Python packages should be adjusted for vampyre - from line 54 onwards.

And of course, no Travis account has been connected to the project yet AFAIK.

[ThomasA]

Notice one of the nice features about the conda package manager: it actually reuses installed packages by linking across the different "environments" if versions are the same (the conda create commands).

[sdrangan]

Just looked at unittest. It looks great to me. But, I will defer the decision to others. Once there is a decision on the framework, I can help move over the tests to the new format. Sundeep

…

On Fri, Jan 27, 2017 at 7:08 AM, Eric W. Tramel ***@***.***> wrote: At the moment, I've only built the framework for running the test files themselves via nose. I haven't specified how to write the tests themselves within the file. One of the nice features of Nose is that it will run anything that it considers a "test." This includes any unittest classes you define in the test files. So, whether the test is a stand alone function or a unittest, nose should run well. There are obvious advantages to using gear unitttest classes, e.g. Not duplicating test configuration and cleanup. So this is certainly an approach we should consider. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANO8IxpaxDDlUZP0CExpDEULGMwHEPF_ks5rWd4qgaJpZM4LvPoa> .