<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, May 1, 2016 at 2:21 PM, Kamil Rytarowski via lldb-dev <span dir="ltr"><<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">It has been noted that LLDB installs its own copy of six.py<br>
(third_party/Python/module/six/six.py) that conflicts with a standalone<br>
one lang/py-six (path in pkgsrc).<br>
<br>
Could we reuse an external version shipped with a system? Alternatively<br>
are there plans to migrate to Python 3 and remove need for it?<br>
<br>
How to address this conflict cleanly?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div>