[gentoo-portage-dev] Re: [gentoo-dev] Web-based Portage Frontendg

[gentoo-portage-dev] Re: [gentoo-dev] Web-based Portage Frontendg

[Jason Mobarak]

On 17:03 Thu 27 Nov     , Jason Stubbs wrote:

[...]
> Okay, so the unit tests are more for the separation of portage rather than the> documentation of it. I did a little search on the definition of unit test and 
> found "Controlled evaluation performed by a system programmer in the 
> Development step to ensure that a piece of program code performs as defined 
> in the specification". Hence, my question. Now, I understand what you want.

To define unit tests with more precision I'll give a portage example -- carpaski
changes massive amounts of global variables, moving them around so that the
portage module isn't dependant on modifying globals (which is a *very* *very*
bad practice in python, you should always know where variables are being
modified and not have "procedures" that modify stuff in the global namespace, or
any other namespace except the most immediate one -- saves headaches and makes
for saner code). These changes to reliance on globals variables has the
potential of breaking many facets of portage the API, so you need a set of tests
that spans across all of portage and effectively tests everything for proper
behaviour, if a failure is encounter it can be quickly located and diagnosed.

Somethings you need to do to get up to speed on unit tests:

1) Read the documentation for the unittest module in the Python standard
library.
2) Read http://pyunit.sourceforge.net/pyunit.html
3) Get a CVS CO of Twistedmatrix.com's CVS and look over how they do there unit
tests, they use their own implementation of unittest but the differences are
minor

> > If you want to add documentation to portage, please look at epydoc.sf.net ,
> > which is basically javadoc for python, this is what I want to use to
> > document portage, it allows for very easy generation of different
> > documentation formats.
> 
> I checked that out when you first mentioned it. It seems pretty easy to use. I
> noticed some documentation already existing in emerge and portage.py. Most of
> the important stuff has no documentation at all, though.

 
[...]
> I can checkout your module by CVS daily and then send you patches if you like.
> As for coordination, there's basically three steps: document, separate, test.
> If there's only two of us, then I think there's two ways to attack it:

This is kind of going to be PITA, we need CVS, sometime in the future I'll find
out if we can get you a developer account, but for the time being if you have a
dedicated server that you can set up CVS on that'd be great, otherwise I can set
you up with an account on my machine (shamash.eece.unm.edu) which is on a
university network and "always on and reliable". Shamash has CVS and we can set
up a portage module on there and I'll do regular commits of our combined changes
to gentoo-src.

> 
> a) I work through documenting everything while you work through separating
> everything that's documented. Once the documenting is done, I can begin unit
> testing and you can join me once the separation is done.  b) You document and
> separate and I unit test what has been completed.

I like (b), 

[...]
> BTW, will this work become redundant by portage-ng?

I hope after portage is separated into a library the code can be incorporated
into "portage-ng", we could very well be working on the beginnings of the next
generation of portage. I want to add "layers" to how everything interacts, key
design patterns being heavy focusing on "plug-in" orientation and
model-view-control. Some keywords you should research if you are interested in
this are Mix-In style programming and the use of interfaces to abstract
aggregate interaction between sections of a program.

"Portage-ng" is being touted as a complete rewrite currently (from what I
remember) and it seems senseless to throw away the 10k lines of code that make
up the current portage system.

Also, please subscribe to the "gentoo-portage-dev" mailing list. I am going to
CC this message to the mailing list.


-- 
-------------------------~
----------Jason-A-Mobarak-~
-aether-at-gentoo-dot-org-~
-------------------------~


--
gentoo-portage-dev@gentoo.org mailing list

[gentoo-portage-dev] Portage Modularisation

[Jason Stubbs]

On Thursday 27 November 2003 17:42, Jason Mobarak wrote:
> On 17:03 Thu 27 Nov     , Jason Stubbs wrote:
> > Okay, so the unit tests are more for the separation of portage rather
> > than the> documentation of it. I did a little search on the definition of
> > unit test and found "Controlled evaluation performed by a system
> > programmer in the Development step to ensure that a piece of program code
> > performs as defined in the specification". Hence, my question. Now, I
> > understand what you want.
>
> To define unit tests with more precision I'll give a portage example --
> carpaski changes massive amounts of global variables, moving them around so
> that the portage module isn't dependant on modifying globals (which is a
> *very* *very* bad practice in python, you should always know where
> variables are being modified and not have "procedures" that modify stuff in
> the global namespace, or any other namespace except the most immediate one
> -- saves headaches and makes for saner code). These changes to reliance on
> globals variables has the potential of breaking many facets of portage the
> API, so you need a set of tests that spans across all of portage and
> effectively tests everything for proper behaviour, if a failure is
> encounter it can be quickly located and diagnosed.
>
> Somethings you need to do to get up to speed on unit tests:
>
> 1) Read the documentation for the unittest module in the Python standard
> library.
> 2) Read http://pyunit.sourceforge.net/pyunit.html
> 3) Get a CVS CO of Twistedmatrix.com's CVS and look over how they do there
> unit tests, they use their own implementation of unittest but the
> differences are minor

Will research up on that.

> > I can checkout your module by CVS daily and then send you patches if you
> > like.
>
> This is kind of going to be PITA, we need CVS, sometime in the future I'll
> find out if we can get you a developer account, but for the time being if
> you have a dedicated server that you can set up CVS on that'd be great,
> otherwise I can set you up with an account on my machine
> (shamash.eece.unm.edu) which is on a university network and "always on and
> reliable". Shamash has CVS and we can set up a portage module on there and
> I'll do regular commits of our combined changes to gentoo-src.

I have a machine that is always on and connected but is not publicly 
accessible. If you could set that up with shamash that would be great.

> > b) You document and separate and I unit test what has been completed.
>
> I like (b),

Okay. Will research unit tests quicker. ;-)

> > BTW, will this work become redundant by portage-ng?
>
> I hope after portage is separated into a library the code can be
> incorporated into "portage-ng", we could very well be working on the
> beginnings of the next generation of portage. I want to add "layers" to how
> everything interacts, key design patterns being heavy focusing on "plug-in"
> orientation and
> model-view-control. Some keywords you should research if you are interested
> in this are Mix-In style programming and the use of interfaces to abstract
> aggregate interaction between sections of a program.
>
> "Portage-ng" is being touted as a complete rewrite currently (from what I
> remember) and it seems senseless to throw away the 10k lines of code that
> make up the current portage system.

That's good to hear. Otherwise would be a bit demotivating...

> Also, please subscribe to the "gentoo-portage-dev" mailing list. I am going
> to CC this message to the mailing list.

Was already there. Even without a role in the development, I still like to 
know what's going on. ;-)

Regards,
Jason Stubbs

--
gentoo-portage-dev@gentoo.org mailing list

Re: [gentoo-portage-dev] Re: [gentoo-dev] Web-based Portage Frontendg

[Jason Stubbs]

On Thursday 27 November 2003 17:42, Jason Mobarak wrote:
> Somethings you need to do to get up to speed on unit tests:
>
> 1) Read the documentation for the unittest module in the Python standard
> library.
> 2) Read http://pyunit.sourceforge.net/pyunit.html
> 3) Get a CVS CO of Twistedmatrix.com's CVS and look over how they do there
> unit tests, they use their own implementation of unittest but the
> differences are minor

All complete. I didn't read every line of twisted's unittests but I get the 
idea. I've also kept it for a reference.

> On 17:03 Thu 27 Nov     , Jason Stubbs wrote:
> > I think there's two ways to attack it:
> >
> > a) I work through documenting everything while you work through
> > separating everything that's documented. Once the documenting is done, I
> > can begin unit testing and you can join me once the separation is done. 
> > b) You document and separate and I unit test what has been completed.
>
> I like (b),
>
> > BTW, will this work become redundant by portage-ng?
>
> I hope after portage is separated into a library the code can be
> incorporated into "portage-ng", we could very well be working on the
> beginnings of the next generation of portage. I want to add "layers" to how
> everything interacts, key design patterns being heavy focusing on "plug-in"
> orientation and model-view-control. Some keywords you should research if you 
> are interested in this are Mix-In style programming and the use of
> interfaces to abstract aggregate interaction between sections of a program. 
>
> "Portage-ng" is being touted as a complete rewrite currently (from what I
> remember) and it seems senseless to throw away the 10k lines of code that
> make up the current portage system.

Well, it seems it is a complete redesign from scratch, but the complete 
rewrite will be much longer coming. If you are still interested in continuing 
your work, I'm still interested in helping. If we do it properly, it should 
not be too difficult to remodel it to fit the design spec of portage-ng once 
it is completed. The components can be replaced by more advanced versions 
later if need be, but as you say there's no point in throwing 10k lines of 
code away.

Regards,
Jason Stubbs

--
gentoo-portage-dev@gentoo.org mailing list