Minimize discrepancy of files between `rattler-build` and `conda-build` artifact content

[boldorider4]

At https://github.com/conda we are seeking to align the behavior of conda-build with that of rattler-build.

conda-build has some unique regular files not present in rattler-build artifacts:

• meta.yaml.template
• git
• files
• has_prefix

rattler-build also has some unique regular files not present in conda-build artifacts

• variant_config.yaml
• rendered_recipe.yaml

would it be possible to include the files that conda-build puts in the packages in the rattler-build builds?

CC: @wolfv

[wolfv]

I would be fine with a PR to add files and has_prefix (although I don't particularly care about them).

For git, it's a weird situation because there can be multiple git sources and conda-build just takes the first one into account afaik (or I don't really know what the contents of this file are).

meta.yaml.template is obviously not possible.

[baszalmstra]

Those files only exist for backwards compatibility right? All installers support the newer files for years. Why not just drop them?

[boldorider4]

meta.yaml.template is obviously not possible. Agreed, I should have not added it in there.

Those files only exist for backwards compatibility right? if they were ever useful, yes, they would be for backward compatibility.

About git, let me clarify internally if we actually need this in the package, in some cases it's an empty file, so perhaps there isn't much of a point.

[wolfv]

Can you also attach some examples of what should be in the git file?

For reference: our rendered recipe contains the exact sources of the git sources (incl. the commit hash) in easy-to-parse YAML under the finalized_sources key.

[boldorider4]

Can you also attach some examples of what should be in the git file?

I'm wrapping my own head around this one, it seems to be useless most of the time, so perhaps I'm ok with letting this one go. Just bear with me until I have a final verdict.

For reference: our rendered recipe contains the exact sources of the git sources (incl. the commit hash) in easy-to-parse YAML under the finalized_sources key.

That is, if the package upstream source is a specific GH hash (e.g. after a release merge commit), correct? We usually use PyPi as source, so in that case there should be no GH hash involved.

[boldorider4]

@wolfv sorry, I forgot to post the example

❯ cat info/git
==> /usr/bin/git log -n1 <==
commit 917025bfee0b58803861ef1e4ace5d0fffa1d7a7
Merge: bfe1a21 4740acc
Author: Valeriu Predoi <[email protected]>
Date:   Tue Jun 3 16:16:44 2025 +0100

    Merge pull request #68 from NCAS-CMS/wacasoft

    Functionality enhancements to address lazy loading of chunked data, variable length strings, and other minor bug fixes
==> /usr/bin/git describe --tags --dirty <==
v0.4.0-159-g917025b
==> /usr/bin/git status <==
HEAD detached at 917025b
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        metadata_conda_debug.yaml

nothing added to commit but untracked files present (use "git add" to track)

[boldorider4]

That is, if the package upstream source is a specific GH hash (e.g. after a release merge commit), correct? We usually use PyPi as source, so in that case there should be no GH hash involved.

Hi @wolfv, can you clarify this?

I need to revive the conversation about letting git go or align to your interpretation of its purpose.