On 15 July 2017 at 16:00, Ned Deily <n...@python.org> wrote: > On Jul 15, 2017, at 01:51, Nick Coghlan <ncogh...@gmail.com> wrote: >> Rather than attempting to change how site-packages works (which >> wouldn't help until 3.7+ anyway), the main missing piece in the status >> quo is the equivalent of a "mergewheel" operation that creates those >> multi-SOABI files and thus allows both sets of binaries to be added to >> the same environment (the same way Linux distros do for the system >> site-packages directory). > > Without thinking too much about it, perhaps another option would be for > packagers to provide two wheels: one containing all files needed for the > non-debug case and a second wheel that only contains the debug extension > modules (with their usual unique fila names) and that depends on the first > wheel.
This is essentially what Linux distros do - the debug packages are distinct from the regular ones, but they also have different names, so there's nothing keeping you from having both installed on a given system at the same time. However, there's a missing primitive for that in our case: we expect wheel archives to define independent package trees, with namespaces package being the only means of injecting your own files into another wheel's packages, so the debug and non-debug builds conflict by default. This means that for the specific problem of injecting debug versions of packages into a project, we're probably better off encouraging the use of package shadowing idioms that are more akin to the way LD_LIBRARY_PATH works than we are changing the way user site-packages works in general. Conveniently, we also already offer the key building block for that: virtual environments with --system-site-packages enabled. That is, if folks want to run the debug versions of their Python extensions without having to duplicate all their pure Python modules, we'd encourage them to: 1. Create a virtualenv with --system-site-packages and SOABI=cp35dm (for example) 2. Install the debug versions of any components with extension modules into that virtual environment (since SOABI=cp35m modules won't load) 3. Run the debug version from that venv One of the key benefits of encouraging that model is that it's general: it works for *any* case where you want to override the default version of a package, not just those where you want to run it against a different SOABI definition. We're missing a useful building block for *sharing* debug binaries between different venvs, but that's also a problem that's amenable to more general solutions (with the main one that comes to mind being a way to "chain" virtual environments, such that you can easily add a *.pth file to a venv that injects the site-packages for one of more other venvs into sys.path) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
