Closed maresb closed 2 years ago
Usually a recipe can be converted to noarch when it doesn't make essential use of any selectors (i.e. comments like # [py<38]
).
The recipe currently proposed in #49 has
build:
number: 0
skip: true # [py<38]
and
requirements:
build:
- python # [build_platform != target_platform]
- cross-python_{{ target_platform }} # [build_platform != target_platform]
The first can be replaced by adding >=3.8
to each - python
requirements item.
The second is necessary to cross-compile for osx-arm64. (Without it, we get Bad CPU type in executable
as in #52.) I believe that a noarch package should work fine under osx-arm64, but we should test this. Then there is no need to cross-compile and we can delete the build requirements block.
Comment:
Currently we build one package (technically base/main pair) per platform per Python version. In the case when a package does not need to be built differently depending on the platform / Python version, Conda offers an alternative called a "noarch" package. In this case, just a single package is built (from Linux).
If my assumption is correct that PyMC is a purely-Python frontend to Aesara, then I think it makes sense to eventually convert this to a noarch feedstock.
An example of a noarch feedstock is aeppl. It can be noarch because all of the compiler stuff is encapulated in tthe Aesara build process.
An advantage is faster, simpler builds which eat up fewer resources. A disadvantage is that we lose the multiplatform tests. (With noarch, the only tests which are run are for the build platform which is Linux.)
I think it makes sense to postpone the implementation of noarch due to the testing benefits. Once we are convinced that things are stable and that the only platform-specific differences arise are at the level of Aesara, then it makes sense to switch.