Emerge: Dependeny optimation

[Ralf Habacker]

Sascha L. Teichmann schrieb:
> Hi Ralf,
>
> Am 20.07.2010 12:59, schrieb Ralf Habacker:
>   
>> Sascha L. Teichmann schrieb:
>>     
>>> Hi together,
>>>
>>> some of you may heard me talking about the "emerge -j/-k" stuff at
>>> the KDE for Windows meeting here at Osnabrück/2010-06-05. Now its
>>> finally there! :-)
>>>
>>> We've have made some improvements to emerge that allow us to set
>>> it up in a more automated/unattended environment to build
>>> Kontact Enterprise 5 (KDE/PIM E5).
>>>   
>>>       
>> This looks very good.
>>     
>>>   I - Plotting the build dependencies graph as a dot graph.
>>> [...]
>>>       
>>
>> An issue i found while running
>>
>> python bin\dependencies.py enterprise5/kdepim-e5 > kdepim-e5.dot
>>
>> is that a debug line is printed at the top of the dot file  - not sure 
>> yet where it came from.
>>     
>
> From inside the portage stuff. If setting EMERGE_VERBOSE=0 the
> line will vanish.
>   
we need to save/set and restore this somewhere in dependency.py

>   
>> Another little issue i found is a naming problem - In portage.py there 
>> is a new  function def get_packages_categories - in emerge function are 
>> normally written in Camel Case with first character lowercase, so it 
>> should be  def getPackagesCategories
>>     
>
> Can fix that. For new code I prefer following PEP8 [1]. Is there an
> official style guide for python code in emerge? 
not yet - a quic ksearch shows that code uses
- 4 spaces indention
- mixedCase (differs from CapitalizedWords by initial lowercase 
character!) for function and naming convention (which is defined in the 
PEP8)
- CapitalizedWords for classes and variables
- Whitespace in Expressions and Statements is used partly following PEP8 
(need probably to be adjusted)
- Documentation Strings mostly follows PEP8

If I have forgotten some import define, let me know  - I guess the 
required corrections are a mid time goal  :-)

> Most of the stuff I saw in emerge follows a C++/KDE alike and unpythonic style with lots of redundant brackets. Should I adjust my code?
>   
yes, please - as far i can see this means to only change method names

<snip>
> Okay, I'll write an explict output function to be used in the
> dot visitor. The str() is used for other purposes too which I
> don't want to break.
>   
thanks - I have seen this in svn
>   
>> Second I suggest to add an additional emerge command like
>>
>> emerge --print-dependencies <package>
>>
>> to make this features callable in the normal way.
>>     
>
> That would be nice. The reason while I haven't done it is
> the way the emerge.py driver is written. There is no
> main() function and would the parsing of the
> program parameters is done by hand. The options parsers
> coming with python not used. I don't want to take
> the same line. I clearly see potential for some refactoring
> here. 
okay.
> In my opinion that should be done after the merge.
>   
agreed

<snip>

>>> III - emerge -j
>>>   
>>>       
>> I will take a look later
>>     
>
> Forgot to mention that Python 2.6 is needed to use this
> because we make use of the multiprocessing API.
>   
does anyone uses still 2.5 ? 
We can raise the minimum version in README
>   
>>> You find our emerge changes in the intevation-merge branch [4].
>>> It would be nice to have merged them back into trunk. :-)
>>>  
>>>       
>> I will take some time for merging the stuff into trunk.
>>     
>
> Andre Heinecke may assist you with this because he merged
> all changes from trunk into our branch already.
>   
thanks for this offer.

Ralf