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-boun...@lists.llvm.org] On Behalf Of Pavel > Labath via lldb-dev > Sent: Tuesday, May 03, 2016 4:01 AM > To: Kamil Rytarowski <n...@gmx.com> > Cc: LLDB <lldb-dev@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- > d...@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- > d...@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-boun...@lists.llvm.org] On Behalf > >>>> Of Kamil Rytarowski via lldb-dev > >>>> Sent: Monday, May 02, 2016 4:36 PM > >>>> To: Reid Kleckner <r...@google.com> > >>>> Cc: LLDB <lldb-dev@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@lists.llvm.org <mailto:lldb-dev@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@lists.llvm.org > >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >> > >> _______________________________________________ > >> lldb-dev mailing list > >> lldb-dev@lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >> > > > > > > _______________________________________________ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
