tfiala added a comment. In http://reviews.llvm.org/D13880#271483, @tfiala wrote:
> In http://reviews.llvm.org/D13880#270742, @zturner wrote: > > > Todd, do you have any good ideas on how to organize this and make it play > > nicely with python's module / package system? `dotest` is just an > > arbitrary script under lldb/test and is not part of any installed package > > or anything. At the same time, third party code needs to be in a > > centralized place at the top-level in case it needs to be tracked or > > audited by legal people. So I don't think we can put six under `test` (nor > > would it even make sense to, since that wouldn't help people under > > lldb/scripts who also want to use it). > > > > So somehow `lldb/scripts` and `lldb/test` both need to be able to import > > from `lldb/third_party/Python/modules`. > > > > I know this isn't really the "pythonic" way, because it expects everything > > to be nicely organized packages with a nice hierarchy, but dotest is > > treated as a one-off script. I don't really want people to have to install > > `six` via setuptools or anything because it just adds an unnecessary extra > > step which is a regression from the status quo. > > > > Do absolute imports help us? > > (https://docs.python.org/2.5/whatsnew/pep-328.html) > > > > I think this question speaks to a more general problem of: "How do we > > re-use python code across tests and scripts?" Do you have any suggestions > > that can make this work cleanly? > > > Hmm, registering that I see the question. I need to think about it. > > Generally I have an upper level script (such as dotest.py in our case) that > gets called directly, and adds paths relative to its script directory to set > up all the other bits it needs to find. One example of where I do this in > lldb is a util that probably nobody else uses, > utils/sync-source/syncsource.py. It imports os and sys, and from that, > bootstraps its sys.path (PYTHONPATH) by adding the script-file-relative lib > dir to the python path. > > So the technique is find an anchor point (in the case above, dotest.py) and > have it add the script-relative path to the python path. > > I do the same thing to adjust the pylint .pylintrc python path, so that > pylint can find not only the lldbtest path, but also the lldb module > executable (via lldb[.exe] -P). That example would be in test/lldb_pylint_helper.py (which also documents how to use it to adjust your global pylintrc to make this all work, which becomes a bootstrap process much like what I think you're asking about here, albeit in the context of getting the python path setup for pylint rather than for the file itself --- but each file could have a little loader that does something like that). > Not sure if that helps? http://reviews.llvm.org/D13880 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
