Improved what is conda forge section.

[shloka-gupta]

This Pull request aims at fixing #1645 The docs earlier suggested that the only way of contributing to conda-forge was by contributing to packages. This PR tries to improve that.

PR Checklist:

• [X] make all edits to the docs in the src directory, not in docs or in the html files
• [X] note any issues closed by this PR with closing keywords
• [ ] put any other relevant information below

[shloka-gupta]

@beckermr @kathatherine can you please have a look.

To be honest, I was extremely tempted to work on https://github.com/conda-forge/conda-forge.github.io/issues/1282 all at once. But I think baby-steps and smaller PRs are a better way to approach the problem.

[beckermr]

Looks pretty good!

[shloka-gupta]

Hello, @jaimergp I committed the suggestions.

Also, another question- may sound silly... But I'll play my newbie card and take my chances. 😅 I believe creating more/maintaining recipes is a contribution as well? Although it's not in the docs yet... Maybe the person can be redirected to staged recipes?

[jaimergp]

A part of that is mentioned in the "Contribute new packages" link, but maybe that's too focused on new additions. We can add one more bullet point reflecting the need of maintainers in orphaned feedstocks. Finding orphaned feedstocks is a different issue, though. One can search for open PRs across conda-forge, and sort by age (as in this query), but it's not perfect and very noisy. Maybe somebody else from Core wants to chime in.

[BastianZim]

Finding orphaned feedstocks is a different issue, though.

Might make sense to revive https://github.com/conda-forge/cfep/blob/main/cfep-10.md

[shloka-gupta]

@BastianZim

I have a few questions now... Again.

1. Can't the process be automated? The way we add the 'stale bot'. If a PR/Issue has not been active for over say 30 days.... We close it. In a similar way for a recipe.

2. Out of context but -- while reading a blog, one of the blogs suggested addressing 'bad recipes' as a good small starter contribution.

What's a 'bad' recipe? Are there any parameters to define a 'bad' recipe?

3): Follow up on 2: In a blog it's said--

meta.yaml---A file that contains all the metadata in the recipe. Only package/name and package/version are required.

build.sh---The script that installs the files for the package on macOS and Linux. It is executed using the bash command.

bld.bat---The build script that installs the files for the package on Windows. It is executed using cmd.

run_test.[py,pl,sh,bat]---An optional Python test file, a test script that runs automatically if it is part of the recipe.```

[shloka-gupta]

...I am not aware of the difference between conda-build and conda-forge,

BUT can the same parameters be there for conda-forge recipes? Or listed somewhere so that a new contributor can follow them?

(For some reason GitHub won't take more characters in my previous comment)

[BastianZim]

I have a few questions now... Again.

That's what we're here for! :)

Let me try to answer your questions in a list to separate them.

1. Which process are you talking about that should be automated exactly? If you mean finding outdated feedstocks then yes, that can be done. The missing part here is currently the CFEP (Conda-forge enhancement proposal) which needs to be accepted by the core team first.

2. A bad recipe can be many things but generally speaking, it's a recipe that isn't following best practises. These can be:

   1. Dependencies are not correctly specified. Either incorrect dependencies or incorrect versions
   2. The meta.yaml follows an old style that conda doesn't use anymore
   3. The license is not correct
   4. The package is not noarch but could be (That wastes CI resources)
   5. ...

   The different parts do not necessarily constitute a good/bad recipe. For example, a build.sh and bld.bat script are not always needed. Most python based recipes just specify a script: {{ PYTHON }} -m pip install . -vv under build which is sufficient. The only time a separate file is normally used is when the script requires multiple steps. Same goes for the run_test file.

3. conda-build is what actually builds the package from the recipe and conda-forge is an organisation that offers a standardised and automated environment in which conda-build can be run. If you look at a feedstock, you will actually find that the CI invokes conda-build to build the recipe (Although we are using mambabuild nowadays which uses conda-build but with the mamba solver which speeds things up) so they are not competing tools. Conda-forge is just an organisation that standardises a lot of things (Compilers, the way recipes are built, uploading of the package, etc.) and provides a lot of tooling so that it is easier to add a package. Otherwise all of the work that the CI currently does would have to be done manually by each uploader.

[jaimergp]

Moved to index.rst and remixed with https://github.com/conda-forge/conda-forge.github.io/pull/1699