Conda 23.3.1: what shall be the content of build.sh?

Question

I found grayskull for creating meta.yml files and I found this github action for publishing on conda.

However, said github action require a build.sh file and according to the official guide such a file must contain "...the text exactly as shown:"

$PYTHON setup.py install     # Python command to install the script.

Nevertheless, newest project have pyproject.toml and I am not sure the above guide applies today since it is fairly old, apparently.

As for conda 23.3.1, what shall be the content of said build.sh?

EDIT: The question has been closed due to that it has been considered opinion-based.

Unfortunately, it is not, as the following Theorem shows.

Theorem: The question is NOT opinion based.

Proof: By contradiction assume that the question is opinion based. Then, there should not exist any non-opinion based guide explaining what shall be included in build.sh. However, an official, non-opinion based guide exists and it is here, which contradicts the initial hypothesis. Hence, the question is not opinion-based. QED

Answer 1

I found a sort of answer triggered by the comment I received that pushed me in searching towards the right direction.

I decided to share my learnings (that may not be 100% accurate) that I hope will give some insights on how the conda package machinery work.

The way to go today (2023) is grayskull, that I mentioned also before. That tool generate meta.yml files starting from pypi packages (and not only from pypi, you can even use a sdist as a staring point, see grayskull docs).

If your package is pure python code (plus some data eventually), then the meta.yml generated from grayskull contain all the information needed for building your conda package. You should edit such meta.yml file a bit though, for example you should edit the recipe-mainteiner field. Then you can run conda build and you should get your conda package.

In reality, things are a bit more complex.

In-fact, in order to make a conda package you need a recipe. What's that? A recipe is a folder that contains a meta.yml a build.sh and a bld.bat files at least, plus some optional files such as run_test.[py,pl,sh,bat] where you specify how your package shall be tested. A recipe can also include patches files and resources like icons, etc.

But what is the purpose of these additional build.sh, etc. files?

Well, if your package has more than python code but include e.g. additional code written in other languages, then you should explain how such code shall be processed. For example, if in addition to python code you have some C source code. In in the build.sh you specify (among other things) how such C code shall be compiled. No need to say that you cannot pre-compile it because then the compiled code would be platform specific. The same principle applies to tests: you may add a run_test.[py,pl,sh,bat] where you specify how you package shall be tested.

However, for what I understood, if the build process of your package is only made of few lines and the tests are rather straightforward, then you can inline such info by using the Section build and tests of the meta.yml file instead of having separated build.sh, etc. files.

Note that in the easiest case of pure python source code, as mentioned in a comment, you have that build is just

{{ PYTHON }} -m pip install . -vv

whereas test is just :

import your_package

which is exactly how grayskull fill up such fields in the meta.yml when you generate it from pypi. Now that such info is included in the meta.yml file you don't need any build.sh, bld.bat and run_tests files.

Examples of recipes can be found, as already pointed out in a comment, here whereas a guide for conda recipe can be found here. - but still, it is from 2018.

In summary, the great thing of conda, for what I understood, is that it can package stuff written in different languages.

But there is more: it seems that conda handles dependencies better than other tools (again, for what I read, so take it with a grain of salt).

However, there have been many complains about its speed, and that is true. It is terribly slow in its default setting. However, you can install libmamba that speed up things drastically - and that I can confirm that it's true.

I hope that this summary is not too wrong and it should answer the initial question on what should be in the build.sh file.