copy_file monkey patch fails when bdist_wheel

[cykerway]

This monkey patch seems to give errors when bdist_wheel as it can create (temporary) broken links. I'm having trouble reproducing it, but I can give a brief description here:

If a symlinks to b at source, and a is created before b at destination, then a becomes a broken link there. Somewhere in the bdist_wheel process is not happy with it and throws a file-not-exist error. I guess this is because os.path.exists(...) returns false on broken links during some verification.

I can build the wheel when commenting out this monkey patch, but you know then all links are followed and the wheel is bigger.

Env: wxPython 4.0.7 on Fedora 35. (GTK2 if that matters.)

Phoenix/setup.py

Lines 278 to 297 in 9a8a9b0

	def wx_copy_file(src, dst, preserve_mode=1, preserve_times=1, update=0,
	link=None, verbose=1, dry_run=0):
	if not os.path.islink(src):
	return orig_copy_file(
	src, dst, preserve_mode, preserve_times, update, link, verbose, dry_run)
	else:
	# make a new, matching symlink in dst
	if os.path.isdir(dst):
	dst = os.path.join(dst, os.path.basename(src))
	linkdst = os.readlink(src)
	if verbose >= 1:
	from distutils import log
	log.info("%s %s -> %s", 'copying symlink', src, dst)
	if not dry_run and not os.path.exists(dst):
	os.symlink(linkdst, dst)
	return (dst, 1)
	import distutils.file_util
	orig_copy_file = distutils.file_util.copy_file
	distutils.file_util.copy_file = wx_copy_file

---

Not sure if this is related: pypa/pip#3500

[cykerway]

Should you get interested, this diff shows the problem I encountered:

cykerway@2be3e6a#diff-60f61ab7a8d1910d86d9fda2261620314edcae5894d5aaa236b821c7256badd7R277-R295

May not be the best solution, just what I came up so far.

[swt2c]

I think this works around this same issue in master branch:
aa8430a

[cykerway]

OK I can confirm the master branch has fixed it. Any chance we can have this patch backported to its Fedora SRPM? AFAIK the latest wxPython on Fedora 35 is still 4.0.7 which was released ~2 years ago. Would it be possible to upgrade to something like 4.1.1?

[swt2c]

OK I can confirm the master branch has fixed it. Any chance we can have this patch backported to its Fedora SRPM? AFAIK the latest wxPython on Fedora 35 is still 4.0.7 which was released ~2 years ago. Would it be possible to upgrade to something like 4.1.1?

I'm thinking probably not on the backport because the Fedora package doesn't build a wheel. It also doesn't use the bundled copy of wxWidgets - it uses the system copy of wxWidgets, which is at 3.0.5.1. That's the main reason that the Fedora package has remained at 4.0.7. I would consider upgrading wxPython once there is a stable release of wxWidgets 3.2.0, or perhaps another release on the 3.1.x branch.

[cykerway]

Right, I forgot the close relationship between wxPython and wxWidgets.

I just compiled wxPython 4.1.1. The problem doesn't exist in 4.1.1. Good.