[lldb-dev] Redundant six.py copy

Tue May 3 02:00:48 PDT 2016

We could have a cmake option, say -DUSE_BUILTIN_SIX=true|false
(default being whatever you like, but I'd like to avoid autodetection,
as that can produce unexpected results). Distrubution maintainers can
set it to false (which will prevent six.py from being installed by
lldb altogether) and just make the lldb package depend on the six
package. People who don't want to have system dependencies in their
shipped version of lldb, can set it to true and do what they have done
so far...

pl

On 3 May 2016 at 02:20, Kamil Rytarowski via lldb-dev
<lldb-dev at lists.llvm.org> wrote:
> Having private fallback six.py will work for everybody, just it cannot
> be installed into the global path along with Python libraries:
>
> $ pkg_info -L lldb|grep six.py
> /usr/pkg/lib/python2.7/site-packages/six.py
>
> Maybe in lldb/utils/?
>
> chieftec$ pkg_info -L lldb|grep py
> /usr/pkg/lib/python2.7/site-packages/lldb/__init__.py
> /usr/pkg/lib/python2.7/site-packages/lldb/_lldb.so
> /usr/pkg/lib/python2.7/site-packages/lldb/embedded_interpreter.py
> /usr/pkg/lib/python2.7/site-packages/lldb/formatters/Logger.py
> /usr/pkg/lib/python2.7/site-packages/lldb/formatters/__init__.py
> /usr/pkg/lib/python2.7/site-packages/lldb/formatters/attrib_fromdict.py
> /usr/pkg/lib/python2.7/site-packages/lldb/formatters/cache.py
> /usr/pkg/lib/python2.7/site-packages/lldb/formatters/cpp/__init__.py
> /usr/pkg/lib/python2.7/site-packages/lldb/formatters/cpp/gnu_libstdcpp.py
> /usr/pkg/lib/python2.7/site-packages/lldb/formatters/cpp/libcxx.py
> /usr/pkg/lib/python2.7/site-packages/lldb/formatters/metrics.py
> /usr/pkg/lib/python2.7/site-packages/lldb/lldb-argdumper
> /usr/pkg/lib/python2.7/site-packages/lldb/runtime/__init__.py
> /usr/pkg/lib/python2.7/site-packages/lldb/utils/__init__.py
> /usr/pkg/lib/python2.7/site-packages/lldb/utils/symbolication.py
> /usr/pkg/lib/python2.7/site-packages/six.py
>
> On 03.05.2016 02:13, Greg Clayton via lldb-dev wrote:
>> 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
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>