[lldb-dev] Redundant six.py copy

[Greg Clayton via lldb-dev]

Can we take care of this with python include path ordering? If we are on a system that has its own six.py somewhere in the python libraries, how is it picking our version incorrectly? Aren't there search paths for the modules? If so, we might need to put any compatibility modules into a specific directory and add that to the python search paths as the last path so it would always pick up any system versions or installed versions first, then fall back to our extra ones in our directories.

Greg

> On May 2, 2016, at 4:08 PM, Ted Woodward via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> 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.
> 
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev