Fix the detection of an unhappy installation path in a venv under Windows

[tramora]

External tools like VSCode can modify the case of the path saved in sys.executable

Fixes #548

The case is indeed reproductible in saving the value of sys.executable and altering its case.

Implementing an automatic test would required extracting a function returning sys.executable and mocking it during the test.
Possible but but a bit overkill.

---

TODO Before Asking for a Review

• Rebase your branch to the latest version of main (or main-v10)
• Make sure all CI workflows are green
• When adding a public feature/fix: Update the Unreleased section of CHANGELOG.md (no date)
• Self-Review: Review "Files Changed" tab and fix any problems you find
• API Docs (only if there are changes in docstrings, rst files or samples):
  • Check the docs build without warning: see the log of the API Docs workflow
  • Check that your changes render well in HTML: download the API Docs artifact and open index.html
  • If there are any problems it is faster to iterate by building locally the API Docs

[popescu-v]

See the comments.

[popescu-v]

See the remaining open comment.

[popescu-v]

A few remaining issues (see the comments).

[popescu-v]

This should be a Path rather than a PosixPath IMHO, to account for Windows paths (and their case-insesitiveness).

[tramora]

You are right, depending on the platform the constructor built either a WindowsPath instance or a PosixPath one.
Fixed

[popescu-v]

We could keep library_root_dir_path as such and comapre it with Path(os.environ["CONDA_PREFIX"]). This should account for Windows case-insensitiveness specifics. Cf. https://docs.python.org/3/library/pathlib.html#general-properties:

>>> PureWindowsPath('foo') == PureWindowsPath('FOO')
True

[tramora]

This WindowsPath case-insensitivess is very interesting and suggests an appealing and elegant way to improve the tests.

But after a review it appears that the majority of the tests are prefix checking (startswith()) and only for 2 cases we have exact paths comparison.

To my humble opinion it is not worth the hassle and this tolower() way seems the most obvious and readable.

[popescu-v]

IMHO, some of this cases could be tackled by using subpath in path.parents, in case we want to test a certain path starts with a subdirectory, or even subpath == path.parents[-2] :

>>> path = Path("/dir1/dir2/dir3/file.txt")
>>> path.parents[-2]
PosixPath("/dir1") # or WindowsPath("/dir1")

Or we can use Path.parts:

>>> subpath = Path("/dir1")
>>>path = Path("/dir1/dir2/dir3/file.txt")
>>> subpath.parts == path.parts[: len(subpath.parts)] # Check path starts with subpath
True

Etc. So, IMHO it's better to systematize on using pathlib because it:

• reduces conditional OS-dependent code
• thus, reduces maintenance costs
• hence, reducing potential bugs or missing OS-dependent code in this respect.

[tramora]

OK let's got for it. The comparisons will have to be exact then (not using startswith() with a prefix any longer).
One must be careful about the exact folder hierarchy to avoid comparison errors.

[popescu-v]

Using (and comparing) pathlib.Paths directly should account for Windows case-insensitiveness and make OS-conditional code in this respect unneessary.