Gentoo Archives: gentoo-portage-dev

From: Alec Warner <antarus@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] Re: equery refactorization
Date: Thu, 04 Dec 2008 05:43:06
Message-Id: b41005390812032143n6e1a6797ve30b0b7bea772c81@mail.gmail.com
In Reply to: [gentoo-portage-dev] Re: equery refactorization by Douglas Anderson
1 On Wed, Dec 3, 2008 at 1:03 AM, Douglas Anderson <dja@××××××.com> wrote:
2 > On Wed, Dec 3, 2008 at 7:21 AM, Michael Smith <michael@××××××××.com> wrote:
3 >> I had the same idea and even began working on a roadmap for it.
4 >>
5 >> Step 1: move gentoolkit to site-packages
6 >> Step 2: move individual command classes to functionally-organized
7 >> module-files
8 >> Step 3: refactor and enhance docstrings to allow primary help/usage()
9 >> function to construct from individual modules. (The goal here is to create a
10 >> drop-in mechanism for adding new modules, so that usage() is automatically
11 >> updated when a new module is added.)
12 >> Step 4: Profit!
13 >>
14 >> Actually another approach would be to create a core __init__.py that handled
15 >> the usage() and getopt functionality I outlined in Step 3 above, and then
16 >> one-by-one modify the individual modules that are in the current equery so
17 >> they could be dropped in.
18 >>
19 >> Thoughts?
20 >>
21 >> Michael
22 >>
23 >> On Dec 2, 2008, at 5:01 AM, Douglas Anderson wrote:
24 >>
25 >>> Hi, I'm interesting in tinkering with equery and doing some
26 >>> refactorization in my spare time. I wrote a script that some people
27 >>> mentioned would be a good module for equery (emeta, it's on bugzilla), but
28 >>> as I was looking into that, I noticed that equery is written as a script,
29 >>> even though it would probably really benifit from being modularized.
30 >>>
31 >>> Again, this is just because I have some free time right now and a
32 >>> willingness to learn about Portage, but I thought I'd check with you guys
33 >>> first. If I'm willing to do it without bother you all too much, would it be
34 >>> something you're interested in me doing? My idea is to set it up more like a
35 >>> Python package than a script, like:
36 >>> /usr/lib/gentoolkit/pym/gentoolkit/equery/
37 >>> /usr/lib/gentoolkit/pym/gentoolkit/equery/__init__.py
38 >>> /usr/lib/gentoolkit/pym/gentoolkit/equery/belongs.py
39 >>> /usr/lib/gentoolkit/pym/gentoolkit/equery/check.py
40 >>> /usr/lib/gentoolkit/pym/gentoolkit/equery/depends.py
41 >>> etc...
42 >>>
43 >>> I think it would increase startup time and make adding or upgraded modules
44 >>> easier in the future.
45 >>>
46 >>> Well, I have a few more questions but I'll wait and see if this would be a
47 >>> positive thing or not.
48 >>>
49 >>> Thanks for your time,
50 >>> -Doug
51 >>
52 >>
53 >>
54 >
55 > Great, I'd like to give this a try, then.
56 >
57 > Michael, I was personally going to go for your "other approach" of
58 > having an __init__.py do all the setup and handle the input and send
59 > the local opts to the individual modules. If you're interested in
60 > working on it together, that would be great. I have a googlecodes repo
61 > that we can work out of, or whatever (same goes for anyone else) :)
62 > I'll also open up a bug for it when I have some work done.
63
64 <nitpick feel free to ignore me>
65 Don't put stuff in __init__.py.
66
67 Make a file called equery (no .py) and do all the work in the modules
68 you import; eg.
69
70 from equery import driver
71
72 if __name__ == "__main__":
73 driver.Run()
74
75 Then put all this code in driver.py (option parsing, signal handling,
76 etc...). Don't try to hide the code in __init__.py; it confuses
77 people who are trying to figure out what the module is for (since
78 __init__.py has very specific duties in declaring what is in the
79 module when you inspect the query module). Putting the code in a file
80 named 'driver.py' or similarly makes it pretty obvious (to me anyway)
81 what the code in that file is for (to drive a program).
82
83 Does that make sense or am I full of crap?
84
85 </nitpick>
86
87 >
88 > A little RFC:
89 > 1) Spaces or tabs? Python standard is spaces, Gentoo seems to be
90 > predominantly tabs. I personally like to use spaces when I'm writing
91 > Python, but if that would annoy everyone later on, I'll stick to tabs.
92
93 Gentoo has no official coding standards. I'd personally prefer spaces
94 (along with basically everything else in the Google Python Style
95 Guide[1]), but I'm probably not going to nitpick. It is my opinion
96 that tabs are used because that is what the tools were written in and
97 it is annoying to change from tabs to spaces ;)
98
99 [1] http://code.google.com/p/soc/wiki/PythonStyleGuide
100
101 >
102 > 2) Are there any other progs that depend on equery and gentoolkit that
103 > you know of? If there are, I can try and keep an eye on things and
104 > create as little hassle as possible.
105 >
106 > Any other ideas?
107 >
108 > -Doug
109 >
110 >

Replies

Subject Author
Re: [gentoo-portage-dev] Re: equery refactorization Douglas Anderson <dja@××××××.com>