Re: Advice wanted: handling weird vendoring situation

[Julian Gilbey <julian@d-and-j.net>]

On Mon, Feb 07, 2022 at 09:27:28PM +0000, Julian Gilbey wrote:
> [...]
> 
> I thought I could address this issue by replacing the vendored copies
> of the library modules by symlinks to /usr/lib/python3.X/, but now
> I've hit another snag: some of these modules import other modules.
> For example:
> 
> pydev_imps/_pydev_SimpleXMLRPCServer.py
> is a very old version of /usr/lib/python3.X/xmlrpc/server.py.  It
> contains within it the following lines:
> 
> from _pydev_imps import _pydev_xmlrpclib as xmlrpclib
> from _pydev_imps._pydev_xmlrpclib import Fault
> from _pydev_imps import _pydev_SocketServer as SocketServer
> from _pydev_imps import _pydev_BaseHTTPServer as BaseHTTPServer
> [...]
> Perhaps another possibility is to have symlinks in the _pydev_imps
> directory to the standard library versions and then temporarily modify
> sys.path to look in _pydev_imps before looking in standard locations.
> I don't know whether this will work, though.

I realise now that this "nice" solution won't work, as the standard
library code says:

import socketserver

so modifying sys.path will just change the value of
sys.modules["socketserver"].  However, the vendored code instead loads
this module to sys.modules["_pydev_imps._pydev_SocketServer"] or
something like that, deliberately avoiding interfering with
sys.modules["socketserver"].

Ho hum.

   Julian