[lldb-dev] Redundant six.py copy

[Ted Woodward via lldb-dev]

This may be true, but telling my users "you have to install six" is a non-starter.

--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

> -----Original Message-----
> From: lldb-dev [mailto:lldb-dev-bounces at lists.llvm.org] On Behalf Of Kamil
> Rytarowski via lldb-dev
> Sent: Monday, May 02, 2016 4:36 PM
> To: Reid Kleckner <rnk at google.com>
> Cc: LLDB <lldb-dev at lists.llvm.org>
> Subject: Re: [lldb-dev] Redundant six.py copy
> 
> 
> 
> On 02.05.2016 18:40, Reid Kleckner wrote:
> > On Sun, May 1, 2016 at 2:21 PM, Kamil Rytarowski via lldb-dev
> > <lldb-dev at lists.llvm.org <mailto:lldb-dev at lists.llvm.org>> wrote:
> >
> >     It has been noted that LLDB installs its own copy of six.py
> >     (third_party/Python/module/six/six.py) that conflicts with a
> standalone
> >     one lang/py-six (path in pkgsrc).
> >
> >     Could we reuse an external version shipped with a system?
> Alternatively
> >     are there plans to migrate to Python 3 and remove need for it?
> >
> >     How to address this conflict cleanly?
> >
> >
> > LLDB should continue to ship its own copy of six.py. It's a single 900
> > line source file. Avoiding this duplication is not worth the headache
> > of asking users to install dependencies. I can't imagine a world where
> > checking in your own copy *wasn't* the intended distribution model for
> > six.py.
> >
> 
> I don't agree here, built in libraries have security and maintainability issues
> downstream. Correct packaging is about removing these builtin redundant
> libraries and link with upstream ones. And in case of a vulnerability (or other
> kind of bug) upgrade a dependency for everybody at once.
> 
> > I'm sure LLDB would take patches to mitigate the namespace conflict.
> > For example, LLDB could do something like "from lldbutils import six"
> > instead of "import six", or we could avoid putting it on sys.path if
> > we notice a system installation of six.
> 
> Dynamic detection of system capabilities isn't reproducible. Also there is a
> scenario of installing lldb and later one of other packages installing global py-
> six.