Remove Quarto packages affected by packaging bug #774
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello, I'm sad to request a large number of Quarto packages to be removed from
conda-forge
.We found that a patch was causing unintended (and very bad) behavior when using Quarto to install TinyTeX. The intent of the patch was to enable the Quarto conda package to install TinyTex into the current conda environment instead of to the path Quarto normally uses,
~/.TinyTex
. The unintended result of the patch was thatquarto install tinytex
overwrites the entire conda environment with a TinyTeX installation.A discussion between feedstock maintainer and Quarto devs yielded a decision to remove that patch. Quarto's own packages and conda-forge packages will all look for TinyTeX in, and install TinyTeX to, the same
~/.TinyTeX
location. Versions1.3.433-1
and1.3.427-2
were released to fix the latest versions.Long-term, we want to enable the Quarto conda package to get its TinyTeX dependency from
conda-forge
.For discussion on marking these packages broken by packaging maintainers and Quarto devs, start here:
conda-forge/quarto-feedstock#25
❤️ Thank you for your time!
Guidelines for marking packages as broken:
instead of marking packages as broken. This alternative workflow makes environments more reproducible.
not technically broken and should not be marked as such.
but should be patched in the repo data and be marked unbroken later.
the maintainers only, we can allow packages to be marked broken more liberally.
conda-forge/core
) try to make a decision on these requests within 24 hours.What will happen when a package is marked broken?
broken
label to the package. Themain
label will remain on the package and this is normal.anaconda.org
CDN picks up the new patches, you will no longer be able to install the package from themain
channel.Checklist:
broken/*
for adding thebroken
label,not_broken/*
for removing thebroken
label, ortoken_reset/*
for token resets)