makespec: Use portable path separators

[bwoodsend]

Use forward slashes – even on Windows – in filenames in generated spec files so that the spec file is independent of the platform it was generated.

[rokm]

Hmm, I'm quite sure that the splash image path needs to receive the repr_filepath() treatment as well - as this is what originally sparked #8004.

[rokm]

Is there a reason why repr() is included in repr_filepath() (i.e., why it returns representation)? I think it would make more sense for the string building part to use %r, while the separator-fixing-function returned only posix path.

(Actually, perhaps it would make sense for all fields in the generated template to use %r as a format string?).

[bwoodsend]

Mind if I scrap the whole makespec.make_variable_path() functionality? The only substitution it knows is replacing the directory of PyInstaller itself which no one should have any reason to use?

[rokm]

Mind if I scrap the whole makespec.make_variable_path() functionality? The only substitution it knows is replacing the directory of PyInstaller itself which no one should have any reason to use?

Hmm, I have a vague recollection of trying to make sense of that part of code sometime back...

As you say, makespec.make_variable_path by default supports only substitution with HOMEPATH. And it seems to be only used by makespec.Path (whose name I absolutely detest), which we apply to entry-point scripts. Which have no business being rooted in PyInstaller's HOMEPATH...

So yeah, go ahead and scrape it.

[rokm]

Mind if I scrap the whole makespec.make_variable_path() functionality? The only substitution it knows is replacing the directory of PyInstaller itself which no one should have any reason to use?

Hmm, I have a vague recollection of trying to make sense of that part of code sometime back...

As you say, makespec.make_variable_path by default supports only substitution with HOMEPATH. And it seems to be only used by makespec.Path (whose name I absolutely detest), which we apply to entry-point scripts. Which have no business being rooted in PyInstaller's HOMEPATH...

So yeah, go ahead and scrape it.

Ahh, HOMEPATH is not PyInstaller's package directory, but its parent directory (usually site-packages). So this was probably supposed to make spec portable if entry-point script was also in site-packages, "next to PyInstaller". Or maybe if for some reason you checked out pyinstaller repository and then placed your code into it, next to PyInstaller importable package. I still find it rather pointless, though.

Plus, you have a 50% chance of having it work on linux with venv, due to venv/lib64 being symlink to venv/lib, and this code not resolving symlinks. So depending of which absolute path you use, it might do that replacement or not...

[rokm]

I think these script paths still need to be made spec-relative, though, because the build process assumes that if they are relative, they are relative to spec directory.

For example, this used to work

pyinstaller --clean --noconfirm program/program.py --specpath spec/

and now it does not (and in contrast to the HOMEPATH thing, I imagine this is used).

Although I suspect that this scenario is party broken anyway, because all given relative paths (icons, etc.) that we later treat as spec-relative would need to be made relative to spec here... But for now, we should at least maintain status quo here.

[rokm]

Those test failures are not directly related to the PR; the matching pattern in

pyinstaller/tests/functional/test_binary_vs_data_reclassification.py

Line 50 in b2b188b

analysis_toc_file = list((pathlib.Path(tmpdir) / "build/test_source").glob("Analysis-??.toc"))

does not account for numbers greater than 99 (e.g., Analysis-105.toc). This probably depends on the test order (I recall seeing that test fail sporadically on the CI), and the changes made here might have rearranged the tests so that the issue occurs more consistently.

[rokm]

This repr() needs to be removed as it is now part of the format.