-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Depend on conda-forge channel by default. #1388
Conversation
Johannes;
I'm not sure the root cause of this as it's beyond my level of gcc expertise but it might be worth debugging on some gcc requiring recipes prior to merging. |
This is great. It always felt a bit wrong to commit general-purpose packages to bioconda rather than some, other, general-purpose channel. It's great conda-forge can be that channel. |
As already discussed strong 👍 from me. I expect also some recipes to fail, do we have a plan how to deal with them? Rebuilding everything would be one option but last time I tried that I found many tarballs missing resulting in many false-positives. |
General purpose on conda-forge sounds great to me, and I agree with Brad and Bjoern about prior testing and planning for failures. |
Johannes; |
I see, thanks Brad for digging into this! In that case, we should definitely wait until the dust has settled. |
One thing to keep in mind is that conda-forge builds its Linux packages using a docker container based on CentOS 6. |
Just now seeing this, very exciting everyone. Looking forward to seeing some more new faces at conda-forge. 😄 A few comments on some of these point raised to hopefully clarify some things. Sorry its a bit lengthy, but I hope this helps give a clear picture of these points. The With regards to CentOS 6, we have been using this for some time and have not had issues with people complaining about GLIBC compatibility. We will likely stick with it for the foreseeable future. At this point, there is a lot of inertia that must be overcome to switch to CentOS 5 so the reason to switch would need to be very pressing. As we are approaching 500 packages in conda-forge, this is no small task to rebuild them on CentOS 5 (or even determine if they need to be rebuilt). The other big reason we are unlikely to switch to CentOS 5 is it is approaching its EOL in less than a year. It would be pretty annoying to switch to CentOS 5 and then switch back to CentOS 6. While there have been discussions about switching to CentOS 5 in the past, it is doubtful anything will change here. TL;DR |
Centos6 is fine with me, I think there are some advantages not going too far back into the past. CUDA, for example, requires Centos6 IIRC. |
@jakirkham if you don't define dependencies in GCC how do you handle run-time dependencies on libgcc? Or is libgcc recommended to depend on? Thanks for your input! |
@jakirkham more concrete if I do not depend on libgcc for some recipes I get a similar error like this:
And how do you recommend are packages handled that needs a more recent GCC, for example because of new language features? |
From my experience, Maybe someone should be put in charge of building different versions of |
@ostrokach this is my thinking as well. We should depend on explicit versions of GCC. Explicit is better than implicit - but there seem to be a large agreement to just use whatever is inside the build-box. |
@bgruening, et al -- devtoolset-2 does some partial static linking with However, systems may not have |
Mhm, I still don't get the whole idea of moving away from a packaged gcc. I On May 11 2016, at 10:52 pm, jakirkham <[email protected]> wrote:
|
There are a few problems with the packaged First, it isn't something we can rebuild on CI. This is actually pretty debilitating because if we discover there is something wrong with the we can't fix it. While the same could be argued about using devtoolset, I have yet to find a bug in devtoolset whereas I know of several we have had to fix with the packaged Second, there is no guarantee about what Finally, and this is the real kicker, if we package In short, packaging |
Sorry this one got lost, @bgruening. devtoolset-2 provides support for C++11. In practice, that seems to cover the code we want to package quite well. If in the future we want to switch to gcc 5.x, there is devtoolset-4 on CentOS 6, which provides |
In any event, the choice of compiler at conda-forge has no effect on what bioconda does internally. In some cases, when code uses Fortran or OpenMP, we use the |
Response to @bgruening in another comment.
👍
👍 We (conda-forge) have meetings every two weeks on Friday at 1400UTC. We are taking a brief hiatus due to conference season, but our next one is scheduled for 3 June. If that works for people, let's add it to the conda-forge hackpad as an item. If not, let's figure out another time when people can meet. |
@jakirkham 3 June sounds good. I think I would be able to attend. I must say that I am still not convinced. Here are my answers to your points from above:
|
Excellent. It is on the hackpad. As for the rest of this, will either write a response later or save it for the meeting. |
I don't think this should prevent us from doing the |
Björn, that's amazing! Thanks!! Dr. rer. nat. Johannes Köster Centrum Wiskunde & Informatica, Amsterdam Harvard Medical School, Boston http://johanneskoester.bitbucket.org On May 25 2016, at 8:53 am, Björn Grüning <[email protected]>
|
Did you make any progress discussing the remaining blockers for the integration of the conda-forge channel lately? |
Yes. We are about to use CentOS 6 (even their image) for building. The next step will be to activate conda-forge as a channel when building our packages. This will for sure cause some problems. We will see. |
This PR enables the conda-forge channel. This will remove some of the workload for maintaining general purpose packages for us. We can still commit general purpose recipes to bioconda, but we should aim to move them to conda-forge at some point. Also, we should start an effort to remove duplication between the two channels.
@bioconda/core please let me know if you are ok with merging this PR.