Re: Python Team membership request for Nicotine package

[François Mazen]

Hello Python Team,

unless I'm mistaken, I haven't received any answer to my requests. Is
the team interested by co-maintaining the nicotine package?


Best,
François



Le dimanche 30 janvier 2022 à 17:38 +0100, François Mazen a écrit :
> Dear Python team,
> 
> I'm working on reintroduction of the nicotine package [1] [2]. This
> software is written in python and Bastian Germann advises me to move
> the package to the Python Team's umbrella [3].
> 
> I really like this idea so I'm requesting to be part of the Debian
> Python team. My salsa login is mzf. I've read the team policy and I
> accept it.
> 
> The package is currently at [4] in good shape. I guess it should move
> to the salsa python team group and comply to the policy (use gbp pq
> for
> instance). So feel free to guide me with the migration.
> 
> Thanks!
> François
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966000
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004401
> [3] https://mentors.debian.net/package/nicotine/
> [4] https://salsa.debian.org/mzf/nicotine



signature.asc
Description: This is a digitally signed message part

Re: Advice wanted: handling weird vendoring situation

[Julian Gilbey]

On Wed, Feb 09, 2022 at 07:39:40PM +0100, Gregor Riepl wrote:
> > 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.

Hi Gregor,

Thanks!

And indeed, that would be a good idea, but I doubt it's going to
happen :( They don't need "vendoring" as far as I can tell, but they
just need a pristine copy of the system library that can be loaded
independently of the system library, so that if gevent patches the
system library at runtime, this package still has access to an
unpatched copy.

So the solution I'm currently in the process of trying is to copy the
version from the oldest supported Python version at Debian package
build time.  We'll see how this goes

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

Unlikely; some of their vendored dependencies date back to Python 2.5!

Best wishes,

   Julian