Bug 481488

Summary:	dev-python/wxpython leaves orphaned wxversion.py[co] files in site-packages
Product:	Gentoo Linux	Reporter:	Mike Gilbert <floppym>
Component:	[OLD] Unspecified	Assignee:	Gentoo wxWidgets project <wxwidgets>
Status:	CONFIRMED ---
Severity:	normal	CC:	jospezial, mgorny, python, wxwidgets
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description Mike Gilbert gentoo-dev

2013-08-17 20:49:41 UTC

I ran into an issue with matplotlib's build system in bug 479970, which caused me to have a closer look at what we are doing with wxpython.

By using alternatives.eclass, the following symlinks get created:

/usr/lib/python2.7/site-pacakges/wx.pth -> wx.pth-HIGHEST_VERSION
/usr/lib/python2.7/site-packages/wxversion.py -> wxversion.py-HIGHEST_VERSION

This creates a couple of problems:

1. When a python package depends on a specific wxpython slot, it actually ends up getting the highest installed version of wxpython.

2. When all versions of wxpython are unmerged, we may end up leaving behind stale wxversion.py[co] files if root ever imported that module.

I would propose that we unslot dev-python/wxpython. Are there any objections from the wxwidgets team?

Comment 1 Mike Gilbert gentoo-dev

2013-08-17 21:13:45 UTC

Hmm... actually reading through wxversion.py, point #1 is not the issue I thought it was. wxversion.py is specifically designed to deal with this.

We still need to figure out a way to deal with the orphaned py[co] files.

Comment 2 jospezial 2024-02-05 23:30:18 UTC

Mike, is this still a thing after more than 10 years now with current (wx)python implementation in Gentoo?
Or do you want to close this?