search

conda-forge / conda-forge.github.io

The conda-forge website.
https://conda-forge.org
BSD 3-Clause "New" or "Revised" License
132 stars 277 forks source link

RFC: Supporting spaces in paths as a first-class citizen #1774

Open hmaarrfk opened 2 years ago

hmaarrfk commented 2 years ago

Your question:

Presently, when users wish to install conda (miniforge/mambaforge or whatnot) it is always a mystery as to whether or not it will work if they have a "space" in their prefix.

One "package" that definitely doesn't work, is Miniconda and other related packages (Miniforge, Mambaforge)

It doesn't have to be that way.

My understanding, is that this is a question of escaping paths correctly.

However, I think this will require many packages to get patched upstream to ensure support.

I think one way to "solve this" (over a long period time) is to create a few images with a space in the build prefix, host prefix, and test prefix.

We would create a conda-forge.yml opt-in option, and start a mass migrator rebuilding all the packages.

Thoughts?

chrisburr commented 2 years ago

Have you looked into what is broken in when using one of the miniforge images? It might be a bug in conda-constructor shell script.

I'm not convinved there is a need for a migration for this. It should probabaly be added to conda-build, similar to what I did a few years ago to make the host and test prefixes have different lengths (https://github.com/conda/conda-build/pull/3386).

The simplest option would be to make it so the test prefix always contains whitespace.

If this is too problematic it could be configurable (e.g. a whitespace_in_test_prefix similar to how prefix_length is already configurable). Once this option exists we can enable it by default in conda-smithy and add an opt out if needed.