Groups > linux.debian.maint.python > #13936

Re: Advice wanted: handling weird vendoring situation

Path	csiph.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!bofh.it!news.nic.it!robomod
From	Gregor Riepl <onitake@gmail.com>
Newsgroups	linux.debian.maint.python
Subject	Re: Advice wanted: handling weird vendoring situation
Date	Wed, 09 Feb 2022 19:40:01 +0100
Message-ID	<DP02J-FXm-1@gated-at.bofh.it> (permalink)
References	<DOjK9-fzz-1@gated-at.bofh.it> <DOsNr-lBo-5@gated-at.bofh.it>
X-Mailbox-Line	From debian-python-request@lists.debian.org Wed Feb 9 18:39:55 2022
Old-Return-Path	<onitake@gmail.com>
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	<debian-python@lists.debian.org> archive/latest/19749
List-ID	<debian-python.lists.debian.org>
List-URL	<https://lists.debian.org/debian-python/>
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	<YgGOwKenQDWOKGOC@d-and-j.net> <YgIV6US1LavT+KXS@d-and-j.net>
Xref	csiph.com linux.debian.maint.python:13936

Show key headers only | View raw

> 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?

Thread

Advice wanted: handling weird vendoring situation Julian Gilbey <julian@d-and-j.net> - 2022-02-07 22:30 +0100
  Re: Advice wanted: handling weird vendoring situation Julian Gilbey <julian@d-and-j.net> - 2022-02-08 08:10 +0100
    Re: Advice wanted: handling weird vendoring situation Gregor Riepl <onitake@gmail.com> - 2022-02-09 19:40 +0100
      Re: Advice wanted: handling weird vendoring situation Julian Gilbey <julian@d-and-j.net> - 2022-02-12 22:30 +0100
        Re: Advice wanted: handling weird vendoring situation Gregor Riepl <onitake@gmail.com> - 2022-02-13 12:10 +0100
          Re: Advice wanted: handling weird vendoring situation Julian Gilbey <julian@d-and-j.net> - 2022-02-16 17:30 +0100

csiph-web