{"action":"created","issue":{"url":"https://api.github.com/repos/conda-forge/staged-recipes/issues/299","repository_url":"https://api.github.com/repos/conda-forge/staged-recipes","labels_url":"https://api.github.com/repos/conda-forge/staged-recipes/issues/299/labels{/name}","comments_url":"https://api.github.com/repos/conda-forge/staged-recipes/issues/299/comments","events_url":"https://api.github.com/repos/conda-forge/staged-recipes/issues/299/events","html_url":"https://github.com/conda-forge/staged-recipes/issues/299","id":147130740,"number":299,"title":"Organising the conda communities and establishing best practices. ","user":{"login":"bgruening","id":469983,"avatar_url":"https://avatars.githubusercontent.com/u/469983?v=3","gravatar_id":"","url":"https://api.github.com/users/bgruening","html_url":"https://github.com/bgruening","followers_url":"https://api.github.com/users/bgruening/followers","following_url":"https://api.github.com/users/bgruening/following{/other_user}","gists_url":"https://api.github.com/users/bgruening/gists{/gist_id}","starred_url":"https://api.github.com/users/bgruening/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bgruening/subscriptions","organizations_url":"https://api.github.com/users/bgruening/orgs","repos_url":"https://api.github.com/users/bgruening/repos","events_url":"https://api.github.com/users/bgruening/events{/privacy}","received_events_url":"https://api.github.com/users/bgruening/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":47,"created_at":"2016-04-09T13:50:08Z","updated_at":"2016-05-01T21:03:22Z","closed_at":null,"body":"We all love conda and there are many communities that build awesome packages that are easy to use. I would like to see more exchange between these communities to finally share more build-scripts, to develop one best-practice guide and finally to have channels that can be used together without breaking recipes - a list of trusted channels with similar guidelines.\r\n\r\nFor example the [bioconda](https://github.com/bioconda/bioconda-recipes) community - specialised on bioinformatic software. They have some very nice guides how to develop packages, they are reviewing and bulk-patches recipes if there are new features in conda to make the overall experience even better.\r\nping @johanneskoester, @daler and @chapmanb from BioConda fame\r\n\r\n[Omnia](https://github.com/omnia-md/conda-recipes) has a lot of cheminformatic software and a nice build-box based on phusion/holy-build-box-64 + CUDA and AMD APP SDK.\r\nping @kyleabeauchamp, @jchodera\r\n\r\nWith conda-forge there is now a new one and it would be great to get all interested people together to join forces here and don't replicate our recipes or copy them from one channel to the other just to make them compatible.\r\n\r\nAnother point is that we probably want to move recipes to `default` at some point and deliver our work back to Continuum - so that we can benefit from each other.\r\n\r\nI can imagine that we all form a group of trusted communities and channels and activate them by default in our unified build-box - or we have one giant community channel. All this I would like to discuss with everyone that is interested and come up with a plan how to make this happen :)\r\n\r\nWhat do you all think about this?\r\nAs a next step I would like to create a doodle to find a meeting data where at least one representative from all communities can participate.\r\n\r\nMany thanks to Continuum Analytics for there continues support and the awesome development behind scientific python and this package manager.\r\nping @jakirkham @msarahan\r\n"},"comment":{"url":"https://api.github.com/repos/conda-forge/staged-recipes/issues/comments/216072561","html_url":"https://github.com/conda-forge/staged-recipes/issues/299#issuecomment-216072561","issue_url":"https://api.github.com/repos/conda-forge/staged-recipes/issues/299","id":216072561,"user":{"login":"jakirkham","id":3019665,"avatar_url":"https://avatars.githubusercontent.com/u/3019665?v=3","gravatar_id":"","url":"https://api.github.com/users/jakirkham","html_url":"https://github.com/jakirkham","followers_url":"https://api.github.com/users/jakirkham/followers","following_url":"https://api.github.com/users/jakirkham/following{/other_user}","gists_url":"https://api.github.com/users/jakirkham/gists{/gist_id}","starred_url":"https://api.github.com/users/jakirkham/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jakirkham/subscriptions","organizations_url":"https://api.github.com/users/jakirkham/orgs","repos_url":"https://api.github.com/users/jakirkham/repos","events_url":"https://api.github.com/users/jakirkham/events{/privacy}","received_events_url":"https://api.github.com/users/jakirkham/received_events","type":"User","site_admin":false},"created_at":"2016-05-01T21:03:22Z","updated_at":"2016-05-01T21:03:22Z","body":"Hi @johanneskoester, sorry your comment got buried in notifications I am afraid and am now discovering while going back through some things.\r\n\r\nGenerally, our feeling here is we want to move away from using a `gcc` package. We have been making steps in that direction. In particular, we now use CentOS 6 with devtoolset-2 for nearly all of our building on Linux. On Mac, we require 10.7 where using the system compiler (`clang`) has C++11 support. This largely meets our needs at present. There are a few exceptions when dealing with OpenMP and/or Fortran. Though we may re-evaluate our strategy here in the future. See this issue ( https://github.com/conda-forge/conda-forge.github.io/issues/29 ) for more details on various proposals.\r\n\r\nWhile it is a nice idea in theory to use a compiler package, in practice this doesn't fair so well. One reason is we can't make any guarantees about GLIBC compatibility on Linux as the compiler could be used to build anywhere. So, we have opted to work on proper docker containers that include a compiler in them. Another reason this doesn't work well is that if we run into an issue with the compiler package (as we did recently), we are largely incapable of fixing it due its long build time that exceeds CI limits. As a result, we can at best use kludgy hacks to try and solve the problem. In the worst case, we find ourselves crippled.\r\n\r\nMaybe a better long term strategy that provides the same guarantees without the same issues would be to create a pseudo compiler package. This package could be used to verify that a compatible compiler can be found. Additionally, this package could be used to perform some sort of configuration to ensure the compiler it found is used. This would allow proper constraints in an explicit manner, but avoid the pains associated with the packaged compiler."}}