Conda-build: Option to prepend/append to `build/string`

[jakirkham]

Currently when a user specifies build/string in meta.yaml, that clobbers the existing build string. So users are responsible for maintaining that content by adding it back somehow. Though this risks going out-of-date if Conda-Build changes how this string is formulated. Also it requires users know how changes in their dependencies might affect their build string and update it accordingly. This is all a bit fragile and asks a lot of users.

It would be useful to have an option to prepend and/or append to the build string instead. This would allow users to add only the content they would like to the build string while leaving it otherwise unchanged. Thus being able to rely on Conda-Build to work its magic.

[mingwandroid]

I'd rather not provide this. What we have now is more flexible.

https://github.com/conda-forge/python-feedstock/blob/master/recipe/meta.yaml#L102

I would support defining something like PKG_BUILD_STRING_DEFAULT though which is set to {{ PKG_HASH }}_{{ PKG_BUILDNUM }} and making guarantees around that not changing.

[jakirkham]

Having some sort of PKG_BUILD_STRING_DEFAULT that includes everything in the string before build/string changes are made would be a good compromise and get the same functionality.

[mingwandroid]

My reason for preferring this method is because it comes with less risk of breaking stuff and also I don't really like having 2 ways to do the same thing for this. Thanks.

[jakirkham]

Completely agree. Was thinking about that as well. Just wasn't sure how easy it would be to expose under-the-hood.

[mingwandroid]

This is pretty easy so I hope to get round to it.

[zhaojack]

Hi guys, running into a similar desire and super glad that this issue already exists and has recent conversations.

If I'm reading the code correctly, I think the "default" current build string is generated through some pretty complicated logic. See here: https://github.com/conda/conda-build/blob/master/conda_build/metadata.py#L548 With that, I don't think just {{ PKG_HASH }}_{{ PKG_BUILDNUM }} is sufficient.

This is especially since the package hash seems to explicitly _ignore_ the more legacy variant keys (such as python r_base lua) that have their own legacy representations in the build string, which I think is what these say:

• https://github.com/conda/conda-build/blob/master/conda_build/metadata.py#L1252.
• https://github.com/conda/conda-build/blob/master/conda_build/metadata.py#L1281
• https://github.com/conda/conda-build/blob/master/conda_build/metadata.py#L1308

This is actually something I was going to file an issue to ask about: What's the reason for explicitly excluding those legacy variant keys from the hash? If they're going to end up contributing to a different build string anyway via special build string parts like py36, then wouldn't it be harmless to have them contribute to the hash too?

Anyway if I'm understanding the code wrong please let me know.

Thanks!

Edit: just to be clear, I like the overall idea of {{ PKG_BUILD_STRING_DEFAULT }}, just a bit concerned about the value it'll be and whether it'll account for the legacy parts.