conda build for libcpptraj on travis about cpptraj HOT 12 CLOSED

What do you think about adding 2nd build on travis for libcpptraj.

So would this be considered part of the current tests or separate? It seems like a fine idea to me - I suppose the only effect is it will make Travis builds just a little bit longer? I would be interested to see what @swails has to say about it since he's much more of a python expert than I am.

from cpptraj.

So would this be considered part of the current tests or separate?

just want to correct, currently cpptraj has two build jobs: https://travis-ci.org/Amber-MD/cpptraj
if implementing libcpptraj, we will add the 3rd job. I don't know how to test libcpptraj, but I am assuming that if cpptraj passed the tests in other build jobs, it will be fine for libcpptraj (with the same building flag). We only upload libcpptraj if all build jobs are successfully.

I suppose the only effect is it will make Travis builds just a little bit longer?

Might be. Perhaps 1-2 minutes longer.

Let's wait to see what @swails say.

from cpptraj.

Man, I thought I'd answered this twice now.

I'm personally -1 on this, since right now pytraj is the only program that depends on libcpptraj. The way things are right now, if Dan breaks API compatibility (and therefore pytraj), that won't get caught as an error in the cpptraj test suite and libcpptraj will get pushed to conda. Which will in turn break the pytraj conda build (which should be the "encouraged" way to install pytraj).

If pytraj controls when libcpptraj is pushed to binstar, then this won't happen.

from cpptraj.

The way things are right now, if Dan breaks API compatibility (and therefore pytraj),

Let's face it - it's not a question of "if", but "when"...

from cpptraj.

If pytraj controls when libcpptraj is pushed to binstar, then this won't happen.

You're right. For example, if Dan breaks the API then uploading libcpptraj to ambermd channel while I am not available to update pytraj, pytraj will be broken. :D

So my solution, like you said, is to let pytraj control building and uploading to ambermd.

This is the workflow

• make a PR to amber-md/pytraj repo
• merge PR if succesul
• travis will automatically rebuild amber-md/pytraj
  • build libcpptraj on the fly (clone from amber-md/cpptraj)
  • build pytraj with just-built libcpptraj
  • perform testing
  • if everything is fine, push libcpptraj and pytraj to anaconda.org

from cpptraj.

Let's face it - it's not a question of "if", but "when"...

for now, I am very scared if seeing Dan updates the header files. (j/k).

from cpptraj.

So we don't want cpptraj to push libcpptraj, am I right?

from cpptraj.

So we don't want cpptraj to push libcpptraj, am I right?

No, we don't.

I will let pytraj do that, so pytraj and libcpptraj can be synced (as you suggested).

from cpptraj.

So this can be closed?

from cpptraj.

yes.

from cpptraj.

@drroe @swails

I just implemented in pytraj, check this out: https://anaconda.org/ambermd

• install

$ conda install -c ambermd pytraj-dev

• update (need to update libcpptraj-dev since conda do not automatically update)

$ conda update -c ambermd pytraj-dev libcpptraj-dev

@drroe
if you want to try, you can install conda by copy and paste this to your terminal

$ wget https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86_64.sh
$ sh Miniconda3-latest-Linux-x86_64.sh
$ # and then
$ conda install -c ambermd pytraj-dev

from cpptraj.

this is upload script after successful build

# adapted slightly from ``mdtraj`` package
# coveralls

echo $TRAVIS_PULL_REQUEST $TRAVIS_BRANCH

if [[ "$TRAVIS_PULL_REQUEST" != "false" ]]; then
    echo "This is a pull request. No deployment will be done."; exit 0
fi


if [[ "$TRAVIS_BRANCH" != "master" ]]; then
    echo "No deployment on BRANCH='$TRAVIS_BRANCH'"; exit 0
fi

anaconda -t $TRAVIS_TO_ANACONDA upload --force -u ambermd -p pytraj-dev $HOME/miniconda/conda-bld/linux-64/pytraj-dev-*
anaconda -t $TRAVIS_TO_ANACONDA upload --force -u ambermd -p libcpptraj-dev $HOME/miniconda/conda-bld/linux-64/libcpptraj-dev-*

from cpptraj.