Upendra and Eric: I look through and successfully ran both your files as they are, without change.  You both show a basic ability to write a simple tkinter app.

Upendra's is more complete as a demo because a) it has two tabs that I can switch between, even though the second is blank, and b) the first tab shows real data -- the list of installed packages on my system.  Eric, if you submit a proposal for this project, I would like to see these upgrades (without copying, of course).

Style nit: I don't like 'import *' and prefer 'as tk' or 'import Tk, Frame, ...'.  This choice partly depends on whether one prefers to use for options the named constants like EXTENDED or literal strings like 'extended'.  You don't need to rewrite now as long as you are *willing* to change, perhaps after discussing which alternative to use, if selected.  Eric: classes should be capitalized, but not all caps.  'Pip' would be fine.  In general, I want to follow PEP8 for new code.

 At least as important as style is structuring for testability, which IDLE is not :-(. Collecting data and displaying data should literally be separate functions: a get_data and a display_data.  (An extra reason to do this in the stdlib context is that only a small subset of CPython buildbots have graphic screens and run gui tests.)  Another change would be to replace

Get_data sends a request to pip and parses the output strings into a Python data object.  Its unittests would use a mock-pip that returns output copied and adapted from real pip request.  The unittest would then check that the data object equals the expected object.

Display_data receives the data object and changes the display.  Testing this is trickier.  It requires the 'gui' resource.  An initial test is that it run without raising an exception.  Some other checks can be automated.  Checking that the display 'looks right' has to be done by a human.