Path: csiph.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!bofh.it!news.nic.it!robomod From: Gregor Riepl Newsgroups: linux.debian.maint.python Subject: Re: Advice wanted: handling weird vendoring situation Date: Wed, 09 Feb 2022 19:40:01 +0100 Message-ID: References: X-Mailbox-Line: From debian-python-request@lists.debian.org Wed Feb 9 18:39:55 2022 Old-Return-Path: X-Amavis-Spam-Status: No, score=-7.2 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, LDO_WHITELIST=-5, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate: -5.5 X-Gm-Message-State: AOAM533/OPthNTtOvLXPZywAQyVSgR/5XJWjX+nSQyi066NVcEEzwlHg Eq4TjGsF0/GXiUTkkB1RQ4lkslG6FoQ= X-Google-SMTP-Source: ABdhPJw45sgIACkA5QyAXK4lYDuPg3YYv/hrP2sKHsrp5bXwCD3TqnLDa7HS0KgT87otpbJNPfw1KA== X-Received: by 2002:a17:907:1627:: with SMTP id hb39mr3289526ejc.407.1644431980044; Wed, 09 Feb 2022 10:39:40 -0800 (PST) MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailing-List: archive/latest/19749 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/50892c15-3ea6-3f8a-106f-7b223e292325@gmail.com Approved: robomod@news.nic.it Lines: 21 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Wed, 9 Feb 2022 19:39:40 +0100 X-Original-Message-ID: <50892c15-3ea6-3f8a-106f-7b223e292325@gmail.com> X-Original-References: Xref: csiph.com linux.debian.maint.python:13936 > 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"]. It seems to me that the "correct" solution would be to motivate upstream not to vendor anything in their source tree. If they really need vendoring to avoid compatibility issues with various environments, they should do so only when building releases. It still wouldn't solve the problem of incompatible system modules, but at least it would make it clearer which versions they require and why. Perhaps they have a maintenance script for updating the vendored dependencies? You could use that to find out how to reverse the changes, or start from a clean slate?