search

conda-forge / conda-smithy

The tool for managing conda-forge feedstocks.
https://conda-forge.org/
BSD 3-Clause "New" or "Revised" License
152 stars 176 forks source link

Is linter check on `build/number` too strict for multi-output recipes? #1697

Open leofang opened 1 year ago

leofang commented 1 year ago

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.

hmaarrfk commented 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.

jakirkham commented 1 year ago

Yeah I've just started setting one number up top with Jinja and templating it through (for example).

hmaarrfk commented 1 year ago

why? that recipe looks strange and error prone now. doesn't it?

leofang commented 1 year ago

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.