@chenghlee @mcg1969 If there is anything that is necessary or helpful (such as specific tests) to merge this PR, feel free to let me know, I am quite interested in this, thanks!

Sorry for the delay in reviewing. But I can't seem to get this to work on a Mac.

For one thing, it seems that the changes were attempted only for the case where the prefix is offered on the command line; that is, <script> -p <install_path>. On the other hand, if you install this in interactive mode, and you supply your desired prefix on the command line, it still rejects it if it contains spaces.

Furthermore, on the Mac, the -p option isn't working. It seems like bash is insisting on breaking apart the prefix, even if I quote it, during the getopt parsing. I can see you tried to change the getopt command to fix that, but I think that on the Mac it's not doing what you expect.

Here's the good news. I modifying the header so that it skips the space checking for interactive input—basically collapsed that entire case statement to PREFIX="$user_prefix". (Note that I removed the eval; that was important.) I was able to build an installer that successfully allowed itself to install into a prefix with spaces, and the environment activated as I would expect. So this is, in theory, a valid approach, it just looks like it needs more work!

Sorry for the delay in reviewing.

@mcg1969 Thanks for the review, and sorry for the delay in coming back to this!

But I can't seem to get this to work on a Mac.
For one thing, it seems that the changes were attempted only for the case where the prefix is offered on the command line; that is, <script> -p <install_path>. On the other hand, if you install this in interactive mode, and you supply your desired prefix on the command line, it still rejects it if it contains spaces.

Furthermore, on the Mac, the -p option isn't working. It seems like bash is insisting on breaking apart the prefix, even if I quote it, during the getopt parsing. I can see you tried to change the getopt command to fix that, but I think that on the Mac it's not doing what you expect.

I didn't have a Mac to test, but I believe the issue is that getopt (as installed by default on macOS) is a different and older version w.r.t. the enhanced one available on Linux, and it's just not possible to parse options with spaces with that version.
Therefore, I've simply removed the use of getopt and used the existing getopts fallback which should work on both systems.

Here's the good news. I modifying the header so that it skips the space checking for interactive input—basically collapsed that entire case statement to PREFIX="$user_prefix". (Note that I removed the eval; that was important.) I was able to build an installer that successfully allowed itself to install into a prefix with spaces, and the environment activated as I would expect. So this is, in theory, a valid approach, it just looks like it needs more work!

Thanks for tip, I've adopted it in the rebase.

I've now tested both the batch and interactive mode, and both works with this updated patch.

N.B: The installed conda environment have issues with the bin/conda Python script, since the shebangs interpreter path cannot contain spaces, but this can be fixed as virtualenv has done:

#!/bin/sh
'''exec' "/tmp/venv with spaces/bin/python" "$0" "$@"
' '''

But that's for another day and repository.

xref conda/conda#186

Right now, conda does not allow spaces in environments, but it can be worked around with explicit paths.

This doesn't work:

$ conda create -n "with spaces" python pip

CondaValueError: Invalid environment name: 'with spaces'
  Characters not allowed: ('/', ' ', ':', '#')

This does work:

$ conda create -p "./with spaces" python pip
WARNING: A space was detected in your requested environment path
'/Users/jrodriguez/tmp/with spaces'
Spaces in paths can sometimes be problematic.

# proceeds as normal

However, once you need to run an entry point executable (or any script with a shebang), problems arise, as expected:

$ conda activate "./with spaces"
$ pip
zsh: /Users/jrodriguez/tmp/with spaces/bin/pip: bad interpreter: /Users/jrodriguez/tmp/with: no such file or directory

I'll see if I can get your virtualenv-inspired solution on upstream conda.

See conda/conda#11676

conda/conda#11676 hasn't landed yet but I am tidying up here and making sure I understand the changes. Sorry about the getopt[s] noise 😬

@jaimergp Thanks for pushing this forward here and on the conda repo, I've added a small follow-up commit.

I just realized that spaces might break a properly initialized conda in base (even with latest versions). So, for now, I suggest we:

• Do not allow check_path_spaces=False in Linux and macOS if conda is present in base.
  • Otherwise, the shebang will have #!/usr/bin/env python (see Make sure conda does not use polyglot shebangs conda#12043), which might take a totally different Python (e.g. system's) if one executes $BASE_PREFIX/bin/conda without preactivating the base environment. An edge case that is tricky to debug, so I'd rather not open that possibility at all.
  • Ideal solution would be deprecating $BASE_PREFIX/bin/conda in favor of $BASE_PREFIX/bin/python -m conda (see Use python -m conda instead of PREFIX/bin/conda in shell functions  conda#11995).
• Recommend conda-standalone >= 22.11.1 in the documentation.

However this PR would allow spaces in prefix for apps that only want to deploy something without conda, so it's still super useful! In the future, if conda can be initialized to a prefix with spaces safely (in some systems like CentOS 7, the "working" approach would drop PS1, see conda/conda#11885), then we can remove the safeguards.

@kenodegard I think there's a Github UI bug and I can't see anymore what changes you were requesting, but I am guessing they are now addressed (hopefully! 😂). See last comment for a summary, but happy to answer any other questions.

Looks like it was not needed after all :D

Oh our dear PR, your time has come! You can now join main 🚀

Thank you @nsoranzo and sorry for the longest review ever :D

Thank @jaimergp and all contributors for the work on this! 🎉

Awesome work everyone!