dragonstyle
commented
1 year ago I want to note that I think the other issue that this raises is that we should be better walling off upgrading and uninstalling version of TinyTex that weren't initially installed by Quarto. We should just attach and use that externally managed version and the update/install/uninstall commands should just error and ask the user to use whatever source they used to install TinyTex to manage the installation.
This summary from @mfisher87:
As far as I can tell, the current code for finding and using TinyTex installations relies on both external and internal installations existing in the same location (IIRC ~/.TinyTex in Linux), so there is functionally no distinction between "external" and "internal" installations of TinyTex. It's more like a "pre-existing" installation than an "external" installation, and Quarto will just try and upgrade it in-place.
is correct in that I will say we really intend not to manage the pre-existing installation, merely to be capable of using it to generate PDF documents.
This comes from discussion at https://github.com/conda-forge/quarto-feedstock/pull/24#issuecomment-1648045509
There was a bug in the conda feedstock because it was trying to make TinyTeX install and available at another place than where Quarto is looking for.
Currently we only check the default installation for determining if this is TinyTeX https://github.com/quarto-dev/quarto-cli/blob/49f1bd16e341f59087b346481756be50281419da/src/tools/impl/tinytex-info.ts#L23-L34
it could be interesting to have a way to configure this in case of a non default installation. It could be as simple as an environment variable that we would use if set.
@dragonstyle opening this to discuss before doing anything.