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

Clarify need of https://github.com/conda/conda-standalone/pull/98 #119

Open
2 tasks done
jezdez opened this issue Dec 5, 2024 · 1 comment
Open
2 tasks done
Labels
source::anaconda created by members of Anaconda, Inc. type::task indicates a change that doesn't pertain to the code itself, e.g. updating CI/CQ, rebuilding package

Comments

@jezdez
Copy link
Member

jezdez commented Dec 5, 2024

Checklist

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

What is the idea?

This seems like a pretty bad design decision to basically make conda-forge (and its sprawling self-service nature) a core part of the conda stack pipeline. Please clarify what the release artifacts copied over from conda-forge are being used for.

Why is this needed?

No response

What should happen?

No response

Additional Context

No response

@jezdez jezdez added source::anaconda created by members of Anaconda, Inc. type::task indicates a change that doesn't pertain to the code itself, e.g. updating CI/CQ, rebuilding package labels Dec 5, 2024
@github-project-automation github-project-automation bot moved this to 🆕 New in 🧭 Planning Dec 5, 2024
@jaimergp
Copy link
Collaborator

jaimergp commented Dec 5, 2024

Please clarify what the release artifacts copied over from conda-forge are being used for.

They are not used in any publishing pipeline. The extracted binaries are copied here for the convenience of end users, especially for the "emergency rescue kit" use case: if someone borked their conda installation with a bad update or pip install they can come here, fetch the relevant conda-standalone executable and try to repair their base environment with something like conda.exe install --prefix path/to/conda/installation whatever-broke. This saves the need of having to access anaconda.org sources, which are archived as .conda, which requires conda-package-handling to extract, which creates a bootstrapping issue if they can't get their hands on cph.

They are copied and not generated here to reduce the surface area of potential build issues. conda-standalone proved to be quite fragile to some build time dependencies back in the day. If they were built in CI we would end up with yet another artifact source we need to account for and debug if it doesn't work.

conda-forge was chosen because it's a community controlled source with friendly TOS for redistribution.

Let me know if that helps clarify the intent of #98. Note that before we had that workflow the conda-standalone binaries were downloaded, extracted and reuploaded manually by yours truly, which is not any better.

Also, I'm curious about the details (and concerns) behind these two statements:

  • "This seems like a pretty bad design decision"
  • "[conda-forge's] sprawling self-service nature"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
source::anaconda created by members of Anaconda, Inc. type::task indicates a change that doesn't pertain to the code itself, e.g. updating CI/CQ, rebuilding package
Projects
Status: 🆕 New
Development

No branches or pull requests

2 participants