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?
Six isn’t a module that is normally installed. I think the pythonic way to do this is tell people “you need to install six before you can use lldb”, but given the number of different ways in which people use it and the different needs, this isn’t ideal.
There are no plans to drop support for 2.7, so it will continue to be needed. Do you actually get an error?
There are currently 83 packages that require py-six in pkgsrc [1] and
changes for a conflict are high, unless someone is using a bare system
with a minimal set of packages.
I'm looking for a solution that is applicable upstream and isn't
patching the sources downstream. Can other users install py-six in their
systems with their python installations?
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'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.
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.
This may be true, but telling my users "you have to install six" is a non-starter.
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
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
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
Should the lldb modules directory be in the global python installation? Build/install puts it in <dir>/lib/python27 on non-windows hosts.