[lldb-dev] Redundant six.py copy

Tue May 3 10:29:30 PDT 2016

Should the lldb modules directory be in the global python installation? Build/install puts it in <dir>/lib/python27 on non-windows hosts.

--
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 Pavel
> Labath via lldb-dev
> Sent: Tuesday, May 03, 2016 4:01 AM
> To: Kamil Rytarowski <n54 at gmx.com>
> Cc: LLDB <lldb-dev at lists.llvm.org>
> Subject: Re: [lldb-dev] Redundant six.py copy
> 
> 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.p
> > y /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
> >
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev