"Ewo is a tool written in Python for the Gentoo GNU/Linux distribution to optimize the recompilation of the whole system, all installed packages. Usually one can simply use emerge -e world and emerge --resume when something bad happens, but sometimes you need to run another emerge process to solve a problem and this alter the desired emerge --resume behavior. Ewo solves this issue and it can be used in general to compile all the packages that have not been updated or replaced after a specific date (CFLAGS, LDFLAG change, compiler upgrade and so on). Using a config file named package.skip the user can avoid useless packages reinstallation, like large binary packages for example."
Created attachment 260911 [details] app-portage/ewo-0.4.1.ebuild
OK, where do I start, hmm. I've been looking over your code on google code. From what I see, you are importing portage and several functions, but for the most part you have a bash script written in python. You are parsing command output for nearly everything. Since you are importing portage there is a wealth of more info available to you. 1) while it may not be important, emerge -e world may not be the entire installed packages list. If a user emerge's an app using -1, --oneshot it would not be picked up by an emerge -e world. That info is available to you from portage directly in a python data type. ex: in fill_world_ng(), you are using portage's vercmp function and feeding it from emerge -p output that you have to run in a subprocess and parse it's output. very inefficient and slow. 2) you are parsing genlop output for the sync time. It is very easy to do directly in python. (minor nitpik) 3) *** MAJOR! You have a distfiles cleaning option. I recently did a major rewrite of gentoolkit's eclean. There is far more to consider than what you are doing. I see potential user upset that files will need to be downloaded again due to them being cleaned by this function. Also I got involved in gentoolkit coding in order to make a number of the utilities usable by other python apps through direct importing of the modules. I was responsible for separating out the equery modules backend code from the display output code. After that I took on eclean and broke it up and made it fully usable by other python based apps. I would recommend using ecleans api rather than continue expanding on yours. 4) you are importing portage, but not listing portage as an RDEPEND. 5) portage has a built-in --exclude ATOMS feature. 6) also in portage-2.2 is the capability of an Age-Set which can identify and re-emerge pkgs that meet the age criteria. See the forums, in portage & programming. http://forums.gentoo.org/viewtopic-t-828918-highlight-ageset.html If you want to learn more about portage's api, as well as gentoolkit's. We'll gladly do what we can. Also there is a python rewrite of revdep-rebuild underway. It too will have a usable API that could be incorporated.
Many thanks for your review, when I wrote ewo I haven't found many portage api docs so I started parsing some output stuff. I agree with you on almost all current issues... I'll take a careful look on all your suggestions
Great to hear. I also forgot, you need to add the python dependency using the python eclass stuff. For some more portage api stuff, look at what I've started in the public_api branch of portage.git. I've neglected it for awhile now, got busy again with other things. You can also look at porthole's portagelib.py backend. There will be a lot more added to the api including doing emerge's within the api. http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=shortlog;h=refs/heads/public_api But for now you will still need to parse a little emerge output for some things. Anyway, I should be in bed asleep :O later...
