(I was eventually going to do this at some point after I verified it was indeed true). It should just be called unittest in a stock distribution.
On Thu, Oct 22, 2015 at 11:29 AM, Todd Fiala <todd.fi...@gmail.com> wrote: > 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 > -- -Todd
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
