Pasted from announcement on gentoo-dev: This is the first, somewhat crude version of my auto-use variable generator. Make sure you read the accompanied README file, and send any feedback this way. It has a very slight issue with auto-enabled use variables from use.desc, which is described in more detail in the README file. You'll need dev-python/pygtk I wrote it in python because most portage tools are in python, so everyone already has that installed. My python skill isn't the greatest, so you gurus can critique that as well :). I invite everyone else to send feature requests and whatnot back to me.
Created attachment 999 [details] generate_use.tar.gz
Hi Bob. Thanks for submission, looking good! 1. Feature request: It would be nice to somewhat extend output logic: make the tool output not only minimal string that should reside in make.conf (what it does now and what should remain the default) but also: a) complete USE string ??b) complement to USE string, such as "-var1 -var2..." where varX are the disabled vars. The rationale: make.defaults may be changed when portage gets updated. Some users may choose to put complete USE specification into make.conf to effectively "lock" their setting. 2. Minor question: I see you use used pygtk bindings instead of tkinter. Was that just because you are familiar with the former of for some more specific reason? I do not want t push you in any direction, its more of a quriosity question. My impression about gui library selection was that tkinter is considered to be standard, at list it is included with almost every python installation. Pygtk will require emerging additional module, but than thats just single python module, no big deal. Both of them provide quite similar functionality, though my understanding was that tkinter does not lock you into gnomish look but rather uses the one provided by active wm/desktop environment. Anyway, this is really very minor issue. I am just quirious about the choise maid. 3. To the real issue: inclusion into stndard tools. I don't think this should be included into gentoolkit, that is the collection of command-line tools after all. It can be distributed as a separate app, but then as I remember there was a discusion of more tools. I think you were mentioning the script that would extract use-vars out of ebuild as well as some other info? I think what we can do is to prepare a collection of gui tools (python gtk/tkinter based) to complement basic emerge and gentoolkit functionality. On the first stages it may consist only of this script. Another feasible tool I can think of would be a gui front-end to emerge (you don't have to do it all, we can just coordinate interested people to this bug#, I will submit parts of this message to gentoo-dev mailing list). Well, there is kemerge already (as well as kebuild and kebuildpart), however that one requires kde. Similar python based tool should definitely be welcome. Please let me know when you think this tool will be ready, I will work on its packaging then. George
I was already planning on doing suggestion 1a for the exact same reason :). 1b is new to me, but trivial to implement, so I'll do that too. As for pygtk, I've done lots of work with gtk+ in the past (mostly with galeon) but very little with python, so having one familiar piece in the puzzle made it a bit easier to work with. Actually, I thought tkinter looked like a tcl/tk app and didn't match the wm, that project was called anygui, IIRC. Anyway, as I've mentioned on the list, the interface is completely separated from the bulk of the code, so I can add other interfaces in at a later date, including a commandline one. I was contemplating having the package use the gtk USE variable, but gtk does not mean pygtk, maybe a new one would be useful after I finish up some of the other interfaces? Also, I do have the USE var collection program just about ready, the working implementation is in perl, so I was going to translate that to python before submitting, and, as it is all cli, it would fit nicely into gentoolkit. I should have that done, and polish off this one very shortly. On the side note of more pygtk/tkinter tools, I'd love to do it, it's been kind of fun to learn some python. I'll probably learn tkinter over the weekend for those who aren't as fond of gtk+ as I.
Actually, while trying to implement 1b, I ran across a problem. I'm not sure how portage handles duplicate entries. For example, you have X already in your USE line in make.conf, but decide to uncheck it. The best the script could do in patch mode would be to generate a -X, but there'd be an X preceding it in make.conf. Seeing as the script already loads in whatever you have in make.conf, I don't think patch mode would give too much additional functionality, and raises a few problems, so I'm going to leave it out for the moment.
Hi Bob So, what's the status of an update (that additional logic you were implemnting)? Another gui tool turned up, so we are getting close to starting gentoolkit-gui collection. George
Sorry about the lack of updates, I've been slightly busy with work and friends getting out of college, etc.. Anyway, I was actually fiddling around a bit with a CLI interface, but I can see that the "USE swiss army knife" scripts have a really good approach to that, so I'm going to put that on the back burner for a while. I can have the extra functionality in now, but, as I can foresee, the interface is going to get a little clumsier. I noticed on the gentoolkit-gui bug it said that gnome-python would be an acceptable dependancy? I stuck to pygtk for less dependancies, but gnome-python would give me a lot more flexibility in gui design, libglade would give even more, but that's asking alot. Anyway, I'll have the updated version with the new logic in sometime today. -Bob
Created attachment 1130 [details] generate_use-0.2.tar.gz Here's the new version. Check out the ChangeLog and README.
WRT acceptable dependencies I would say its pretty much up to you. Since we already started with python/pygtk theme (in both tools) I guess we have set some kind of "standart" by that ;). Also these are gui tools, so the purpose is not to get something tight that would go into almost any minimalistic setup, but rather to provide a nice graphical interface. Of course if some tool would require full new toolbox to support it, it would need to go into a separate package. But as long as it stays reasonably close in reuirements to whatever specification we come up with it should be fine..
Assigning to LordVan as the owner of the "master bug".
Created attachment 4423 [details] Update to pygtk2 (needs pygtk => 1.99) will submit ebuild when the 'freeze' for 1.4 is done.. depends now on pygtk >= 1.99 !!! and gtk2
Created attachment 4426 [details] fixed bug which isn't worth increasing version ;)
added url from gentoolkit-gui bug
added to portage-cvs .. will be in rsync soon (and i hope the file will be mirrored too then :)
