Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable reproducible environments #5489

Open
2 tasks done
ctcjab opened this issue Sep 17, 2024 · 0 comments
Open
2 tasks done

Enable reproducible environments #5489

ctcjab opened this issue Sep 17, 2024 · 0 comments
Labels
type::feature request for a new feature or capability

Comments

@ctcjab
Copy link

ctcjab commented Sep 17, 2024

Checklist

  • I added a descriptive title
  • I searched open requests and couldn't find a duplicate

What is the idea?

conda-build should allow users to provide a conda-lock lockfile so that it can create environments in a reproducible fashion when building (and optionally testing) a package.

Why is this needed?

Because conda-build does not currently support lockfiles, running the same conda-build command on the same revision of a codebase can succeed the first time you run it and fail the second time you run it, due to out-of-band changes (e.g. a transitive dependency publishing a new version). This makes conda-build users' CI jobs unreliable, and makes it harder to find out why a build has broken. If conda-build consumed lockfiles that were versioned in the codebase, it would enable the invariant that every CI job's pass/fail result is a pure function of the revision of the code that it ran against, and so if revision X passed and revision Y failed, the cause of the failure can be found somewhere in the diff between revision X and revision Y.

What should happen?

conda-build should allow users to provide lockfiles which it should use for every environment that it creates as part of the build, bypassing solver-based non-determinism.

Additional Context

No response

@ctcjab ctcjab added the type::feature request for a new feature or capability label Sep 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type::feature request for a new feature or capability
Projects
Status: 🆕 New
Development

No branches or pull requests

1 participant