-
Notifications
You must be signed in to change notification settings - Fork 10
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
Travis tests failing #88
Comments
Conda's dependency resolution algorithm gets stuck at this step:
Normally this happens when you have a large number of dependencies (like we still do) without pinning their versions. The number of combinations of different versions of the packages to satisfy the list of dependencies is so high that the solver does not know what to do. You can see that in action by appending
My personal (brute force) approach in the past has been to pin all the packages to the versions that have proved to pass the tests. That way: 1) the dependency resolution algorithm finishes quickly, and 2) we enable reproducibility by releasing together a version of the code with all the versions of the dependencies that pass the tests with that code. |
I have managed to make some progress by updating
Is the code now ready to work with On the other hand, once
|
Thanks for your help. Im not sure if the code has been tested for scipy >=1.0, but when im back in the office I can test. Can you remember what the issues were? I really didn't like the idea of unpinning environments in the first place (I think @Charlie-George also agrees with me) because conda does some weird unexpected things when installing very large environments. I haven't tested the devel script yet (its on my list of things to do) but I can have a look when I get back. |
Thanks @Acribbs I don't remember exactly the issues with I see why unpinning all dependencies in Best regards, |
Thanks, @Acribbs and @sebastian-luna-valero . Generally I think we should unpin. I think there are three reasons:
Sometimes there is a need to pin, for example to work around bugs in particular releases of software. But then the pinning should be based on exclusion, i.e., I think it is worth taking a step back to see what the issue is, namely: we can't install our cgat-flow software environment on Travis for testing because of a 30 minute time-out. This could be
About these:
To conclude, I am thinking that pinning to make sure the install finishes in a pre-defined amount of time just so that it runs on travis is not the right path. Imagine we pin and we get it to 29 mins. What if we need to add another test? Or another dependency? Thus, I am thinking we should (A) keep everything unpinned and (B) forget about Travis for cgat-flow and rather use our jenkins setup. That being said, there might be optimizations in the install script. For example, we update the environment multiple times - this could probably be stream-lined. |
Looks like scipy is giving problems, maybe we use Andreas suggestion and use @AndreasHeger, you have convinced me that its a good idea to unpin then. However, I am a bit worried about the fact that sebastian found that python and R versions were very old. Should we not at least pin these two packages? I think the primary reason for the build taking so long is the Conda SAT solver (which conda are trying to fix - conda/conda#7700) and the fact that we have quite heavy dependancies. What are your opinions on using cycleCI for cgat-flow instead of Travis?, as you seem (from what I can see at the moment) to be limited by 1000 hours per month rather than per job. Also, for flow we probably only need to test for linux as the pipelines are too heavy weight for OSX. The jenkins setup won't integrate with GitHub though will it? |
Hi, I am looking at a potential fix to the installation issue in #89 Currently the Linux build works but the OS X doesn't. Are we now aiming at supporting OS X builds for cgat-flow as well? That's a real challenge! Although I am happy to follow @AndreasHeger's approach, I would also like to explain my point of view regarding the pinned vs. unpinned environment. I agree that the good thing about having an unpinned environment is that you will install by default the latest versions of all the dependencies in your environment. However, that also has a cost:
From my past experience, the time and effort required to solve those issues is not negligible. On the other hand, having pinned environments provides predictable installations. Regarding the issues mentioned before:
The underlying issue is that none of us has a full-time position to maintain code in a way that installs without issues and is able to keep up with the latest available dependencies out there. We just use a best endeavour approach. Regarding the Travis vs. Jenkins discussion:
Again, this is only my personal opinion but I am happy to proceed with the unpinned approach. Best regards, |
Conda solver slowdown FAQ and recommendations: |
Thanks @sebastian-luna-valero<https://github.com/sebastian-luna-valero>, thats really helpful!
One thing that I'd find really helpful for solving conda issues is being able to access the most recent version of the enviroment that worked correctly and all tests passed, is there an easy way to track this via travis?
…________________________________
From: Sebastian Luna-Valero <[email protected]>
Sent: 25 February 2019 07:29:12
To: cgat-developers/cgat-flow
Cc: Charlotte George; Mention
Subject: Re: [cgat-developers/cgat-flow] Travis tests failing (#88)
Conda solver slowdown FAQ and recommendations:
bioconda/bioconda-recipes#13774<bioconda/bioconda-recipes#13774>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#88 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIUc4SWUz8EEg4GetgjCDzVPGvwuke-Nks5vQ5DIgaJpZM4ahybe>.
|
That used to be the case:
Please note that I have used an old commit for this example, but I think the master branch should always have that functionality by default. The same should happen in our Travis setup. Best regards, |
Thanks @sebastian-luna-valero for sharing the conda issue. Its really helpful and im going to try out their new solver. We arnt really expecting to support cgat-flow in OSX so I was wondering if tests should be disabled as the flow is only tested on jenkins using linux build anyway. I see there are lots of talk of using envronment.yml files and pin packages and thats what I have done for showcase. In the current form I dont think we will be able to get any travis tests passing using the unpinned versions as the solver just takes too long. I really like the idea that was proposed in the conda issue of using meta channels where only the last 1-2 years of packages as I suspect this would speed up the installation by quite a lot by giving the solver less work. |
Hi, I have managed to get the travis tests passing for cgat-flow on both Linux and OS X: However, there are a couple of tests failing for cgat-apps: I would be grateful if someone could have a look before merging. Best regards, |
Thanks so much! So changing the priority increased the resolve time. I think im going to pay closer attention to my channel priority in future. I have had a look over and it looks good, however I remember discussing with andreas about removing xtrace and if I remember rightly he wanted it in. Although I wasn't keen because the output looks rather messy. BW, |
* updates to fix #88 * bugfix * use READLINK * change conda channel order as per http://bioconda.github.io/#set-up-channels * add conda env export for conda_test * disable xtrace errtrace in install-devel.sh * explicitly add conda env export to log * now work with cgat-core and cgat-apps in master
@AndreasHeger it seems the tests are failing due to a kill issue
I assume this is because the conda installation is taking a lot longer than previously?
The text was updated successfully, but these errors were encountered: