Conda-forge.github.io: Hosting of recipes that don't build?

[msarahan]

In a meeting today, we (Continuum) discussed wanting to make conda-forge the canonical host of conda recipes. In doing so, one issue that we identified is the question of recipes that will not build on conda forge, for any of various reasons:

• software that is not available due to licensing constraints (MKL?)
• software that takes too long to build (Qt?)

Continuum is presently considering keeping these packages in a separate public space. Can we discuss whether some recipes on conda-forge are in this special category, and host them here instead? It may be that anaconda.org workers may eventually solve these issues, but these are not yet ready for conda-forge.

[pelson]

we (Continuum) discussed wanting to make conda-forge the canonical host of conda recipes

❤️

In doing so, one issue that we identified is the question of recipes that will not build on conda forge

Aha, yes, interesting question. I'd love to talk about this one in the meeting. Would you mind adding it to the agenda: https://conda-forge.hackpad.com/conda-forge-meetings-2YkV96cvxPG

In principle, I can envisage feedstocks which don't build and which don't upload, though there is some detail there which we should discuss.

[ocefpaf]

In a meeting today, we (Continuum) discussed wanting to make conda-forge the canonical host of conda recipes.

It is the linter isn't it :wink:

[msarahan]

@teoliphant was very impressed observing both the unifying prevalence of conda-forge and its functionality during his recent trip to PyData London. Continuum has long worked for and hoped for the community unification that conda forge is creating. Now it's time to recognize success, get behind it, and see how far we can go.

Oh, and the linter.

[jakirkham]

Have we tried to build Qt?

[msarahan]

It takes 2-3 hours on my 2014 quad-core macbook pro. This is with qtwebengine and qtwebkit, though. There may be ways to build those separately, but the instructions we know are to build them together.

[jakirkham]

Yeah, maybe breaking Qt into pieces might be a good idea. We can always add a metapackage that pulls all the pieces back together.

[msarahan]

yes, It's just a question of how well the build actually works. Sometimes these projects assume direct access to source files, not just headers.

[jakirkham]

That's true. Though we could just download the whole source each time. Admittedly, we will need to think a bit about how to do this right (assuming we are ok with this course of action).

To me, Qt seems pretty bulky. So, being able to grab the parts that one needs would be pretty nice.

Let's split this Qt discussion off into another issue. Maybe at staged-recipes?

[jakirkham]

The MKL point is pretty tricky because we might not be able to have this be a package at all. Reason being we can't allow other people to download it with headers, right? Though we will want to do this in our builds. Let's discuss this more at a meeting.

Any other weird packages you can think of?

[jakirkham]

Another package that one might consider for this list would be cuDNN. Except distribution of this would basically not be possible as it's license is currently formulated. We might be able to build stuff against it and simply not supply the libraries.

[jakirkham]

I think the answer is we do this to some extent. Though it would be good to finish up ( https://github.com/conda-forge/conda-forge-enhancement-proposals/pull/5 ) so it is formalized and documented.