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 |
> |