Open leofang opened 1 year ago
Can you provide an example where this kind of behavior would be desirable?
Honestly, I find that when you pin a subpackage from a multi-output recipe, anything other than that exact
is likely a mistake.
So I would think that having a common build number really helps the rest of the machinery.
Yeah I've just started setting one number
up top with Jinja and templating it through (for example).
why? that recipe looks strange and error prone now. doesn't it?
why? that recipe looks strange and error prone now. doesn't it?
Why? It's common for any feedstock with subpackages. The current behavior is an antipattern for recipes that generate subpackages, as each subpackage can (and arguably should) have its own build/number
. Then, the parent recipe one is redundant.
When working on #1691 I noticed that this check https://github.com/conda-forge/conda-smithy/blob/140a2729aa5aaf79eaa41d958e9422b1fbd49ce6/conda_smithy/lint_recipe.py#L254-L256 is too strict for a multi-output recipe. Either with or without the implicit metapackage, it is legal with conda-build that the top-level recipe does not have
build/number
defined. But while it may make sense to remove the top-level build number in the case of explicit metapackage, conda-smithy's linter can still report an error.