We could also then remove unittest2 from inclusion in the lldb repo.
On Thu, Oct 22, 2015 at 11:28 AM, Todd Fiala <todd.fi...@gmail.com> wrote: > I'd be okay with that. > > The unittest2 stuff looks like it was a vestige of being incorporated > before unittest2 was stock (unitest) on Python 2.[6,7]?. Everyone should > have a unitest included that is effectively what we use as unittest2. > > -Todd > > On Thu, Oct 22, 2015 at 10:05 AM, Zachary Turner via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> I plan to put this in today. Greg, should I just go ahead and delete all >> the unittest2 stuff entirely? TBH I'm all for anything that reduces the >> complexity of the test suite. It's got a couple hundred options that >> nobody uses, seems like we should start whittling away at stuff that >> doesn't get any use. >> >> If you prefer I leave it in that's less work for me since I have that >> patch ready to go, but TBH I'd rather remove it if that's ok. >> >> On Thu, Oct 22, 2015 at 9:50 AM Zachary Turner <ztur...@google.com> >> wrote: >> >>> You can get pretty much the same effect though by just running dotest >>> and passing it the folder that the .py file is in. Then it only runs >>> tests in that folder. You can specify the filename too if you want to >>> limit it to one name. Sure, it's a few keystrokes less to just type >>> TestMultithreaded.py or something, but given the extra complexity and the >>> fact that it's running a totally different codepath, I wonder if the >>> maintenance burden is worth it (I'm guessing no, since apparently it >>> doesn't work well enough right now for anyone to use it) >>> >>> On Thu, Oct 22, 2015 at 9:47 AM Greg Clayton <gclay...@apple.com> wrote: >>> >>>> I believe it would import lldb correctly. I don't tend to run the tests >>>> individually, but if it did work, I would use it more. >>>> >>>> > On Oct 22, 2015, at 9:26 AM, Zachary Turner via lldb-dev < >>>> lldb-dev@lists.llvm.org> wrote: >>>> > >>>> > Todd, Greg, can you guys confirm this is true? The import lldb >>>> would succeed if someone had their PYTHONPATH set up just right, but if >>>> really none of us care about it, I'm with Tamas in that I'd rather remove >>>> it. >>>> > >>>> > On Thu, Oct 22, 2015 at 2:55 AM Tamas Berghammer < >>>> tbergham...@google.com> wrote: >>>> > Hi Zach, >>>> > >>>> > I think nobody is using the "if __name__ == '__main__'" block as >>>> executing a test file directly isn't working at the moment (the "import >>>> lldb" command fails). If you plan to change all test file then I would >>>> prefer to remove the reference to unittest2 from them for simplicity if >>>> nobody have an objection against it. >>>> > >>>> > Tamas >>>> > >>>> > On Wed, Oct 21, 2015 at 8:57 PM Zachary Turner via lldb-dev < >>>> lldb-dev@lists.llvm.org> wrote: >>>> > TL;DR - Nobody has to do anything, this is just a heads up that a >>>> 400+ file CL is coming. >>>> > >>>> > IANAL, but I've been told by one that I need to move all third party >>>> code used by LLDB to lldb/third_party. Currently there is only one thing >>>> there: the Python `six` module used for creating code that is portable >>>> across Python 2 and Python 3. >>>> > >>>> > The only other 2 instances that I'm aware of are pexpect and >>>> unittest2, which are under lldb/test. I've got some patches locally which >>>> move pexpect and unittest2 to lldb/third_party. I'll hold off on checking >>>> them in for a bit to give people a chance to see this message first, >>>> because otherwise you might be surprised when you see a CL with 400 files >>>> being checked in. >>>> > >>>> > Nobody will have to do anything after this CL goes in, and everything >>>> should continue to work exactly as it currently does. >>>> > >>>> > The main reason for the churn is that pretty much every single test >>>> in LLDB does something like this: >>>> > >>>> > import unittest2 >>>> > >>>> > ... >>>> > >>>> > if __name__ == '__main__': >>>> > import atexit >>>> > lldb.SBDebugger.Initialize() >>>> > atexit.register(lambda: lldb.SBDebugger.Terminate()) >>>> > unittest2.main() >>>> > >>>> > This worked when unittest2 was a subfolder of test, but not when it's >>>> somewhere else. Since LLDB's python code is not organized into a standard >>>> python package and we treat the scripts like dotest etc as standalone >>>> scripts, the way I've made this work is by introducing a module called >>>> lldb_shared under test which, when you import it, fixes up sys.path to >>>> correctly add all the right locations under lldb/third_party. >>>> > >>>> > So, every single test now needs a line at the top to import >>>> lldb_shared. >>>> > >>>> > TBH I don't even know if we need this unittest2 stuff anymore (does >>>> anyone even use it?) but even if the answer is no, then that still means >>>> changing every file to delete the import statement and the if __name__ == >>>> '__main__': block. >>>> > >>>> > If there are no major concerns I plan to check this in by the end of >>>> the day, or tomorrow. >>>> > _______________________________________________ >>>> > 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 >> >> > > > -- > -Todd > -- -Todd
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
