Unreproducible build: base_library.zip contains references to source files

[jdcowf]

Description of the issue

.pyc files in base_library.zip contain references to their source files. This is similar to #5377.

Context information (for bug reports)

• Output of pyinstaller --version: 4.2, 5.0.dev0
• Version of Python: 3.8.1
• Platform: Win10 En
• Did you also try this on another platform? Does it work there?
  Did not try on another platform

What I did:

1. Install Python 3.8.2 in 2 locations (e.g. C:\Python38 and C:\Python\Py38)
2. Create a virtual environment from one C:\Python38\python.exe -m venv .venv
3. Create an empty test.py file touch test.py
4. activate .venv
5. SET PYTHONHASHSEED=1
6. invoke pyinstaller --clean -y test.py
7. copy the output to another location
8. repeat steps 2-6 with the other install
9. compare base library of the 2 builds and observe the differences in the .pyc files

More:

The root cause seems to be that the mod.code is not having strip_paths_in_code invoked on it prior to writing it like is done in other areas of the code.

pyinstaller/PyInstaller/depend/utils.py

Lines 92 to 105 in 8666376

	with io.BytesIO() as fc:
	# Prepare all data in byte stream file-like object.
	fc.write(BYTECODE_MAGIC)
	if is_py37:
	# Additional bitfield according to PEP 552
	# 0b01 means hash based but don't check the hash
	fc.write(struct.pack('<I', 0b01))
	with open(mod.filename, 'rb') as fs:
	source_bytes = fs.read()
	source_hash = importlib_source_hash(source_bytes)
	fc.write(source_hash)
	else:
	fc.write(struct.pack('<II', timestamp, size))
	marshal.dump(mod.code, fc)

[rokm]

Well spotted, thanks! The base python location is even more invariant than the virtual environment location, which makes this even harder to notice.

I guess the real challenge here is getting strip_paths_in_code imported without causing import cycles between PyInstaller's modules...