1 |
On Thu, 2013-01-31 at 13:39 -0500, W. Trevor King wrote: |
2 |
> On Sat, Jan 12, 2013 at 12:55:58AM -0800, Brian Dolbec wrote: |
3 |
> > You can get a git clone of my rewrite work at: |
4 |
> > http://dev.gentoo.org/~dolsen/catalyst/ |
5 |
> > |
6 |
> > rewrite branch |
7 |
> |
8 |
> Ah, it's good to see things looking more Pythonic in Catalyst-land ;). |
9 |
> Here's my initial review to push this forward, although I'm not |
10 |
> particularly well-versed in the Catalyst internals. This is branch is |
11 |
> getting to the stage where rebasing will get annoying, so I think |
12 |
> merging stuff that looks good into the master branch should happen |
13 |
> sooner, rather than later ;). |
14 |
> |
15 |
|
16 |
There are a few fixes that should be for sure merged into master. The |
17 |
rest I intend to rebase them into more meaningful complete commits. |
18 |
|
19 |
A couple general answers for questions in this and your next review |
20 |
email: |
21 |
|
22 |
|
23 |
I am halting further changes at this point except for what's needed to |
24 |
debug everything up to this point. I will fix/rebase commits to clean |
25 |
them up as much as possible. I do think that it will be difficult to |
26 |
make complete commits for some changes that do not break catalyst until |
27 |
the remaining commits are also merged. |
28 |
|
29 |
|
30 |
Thank you for enough info for me to google about commit summary, message |
31 |
body. Until now I didn't know about needing to separate them with a |
32 |
blank line. I had never come across that info before, so had given up |
33 |
trying to format them better. Everything I tried had failed. Even |
34 |
googling it now it seems to be everywhere but git's own help. |
35 |
|
36 |
|
37 |
|
38 |
|
39 |
> 321df3b whitespace cleanup |
40 |
> |
41 |
> This looks good, but there are also whitespace cleanups in some other |
42 |
> commits (e.g. 2d36d29). I think we should just run something like: |
43 |
> |
44 |
> for FILE in $(git ls-tree -r --name-only HEAD | grep -v 'bz2$'); do |
45 |
> sed -i 's/[[:space:]]*$//' "$FILE" |
46 |
> done |
47 |
> |
48 |
> and have done with it ;). |
49 |
|
50 |
yeah, that requires way more knowledge about those tools than I know. |
51 |
For me, I open a file, the editor does the cleanup automatically. If I |
52 |
don't separate them when committing, then... If I didn't edit the |
53 |
file... |
54 |
|
55 |
> |
56 |
> 38cd3bb add more configured defaults |
57 |
> |
58 |
> List the new settings (distdir, repo_name, packagedir, port_tmpdir, |
59 |
> options, snapshot_name) in the commit message so I don't have to read |
60 |
> the diff. Probably explain why you think they should be configurable |
61 |
> as well. `options` is also a pretty ambiguous name. |
62 |
|
63 |
Now that I know how to blab on in a message body with a brief summary, |
64 |
yeah :) |
65 |
|
66 |
"options" was existing and seems comparable to FEATURES for emerge in |
67 |
make.conf. Suggestions for a new name? |
68 |
|
69 |
> |
70 |
> 016704a use the new configured snapshot_name and portdir settings |
71 |
> |
72 |
> Rather than a separate add (38cd3bb) and use (016704a), I think it |
73 |
> would be better if new options had their addition and use rolled into |
74 |
> a single commit (e.g. add snapshot_name and use it as one commit, add |
75 |
> portdir and use it as another commit). |
76 |
|
77 |
I will in the rebase, making new commits. |
78 |
|
79 |
> |
80 |
> This might also be a good place to move the path construction over to |
81 |
> use os.path.join(). |
82 |
|
83 |
Yes, I agree, but I am still getting accustomed to the code, so was |
84 |
holding off that for a bit. Need to debug changes first. I am also |
85 |
contemplating stealing the path() from layman which joins a list of |
86 |
partial paths. I've noticed it could simplify code in many places that |
87 |
join more than 2 partial paths. |
88 |
|
89 |
> |
90 |
> fefd501 use the portdir setting rather than hard-coded path |
91 |
> |
92 |
> Good to merge. |
93 |
> |
94 |
> 63a25eb Remove self.mounts and self.mountmap's use of paths for keys |
95 |
and paths. Migrate more hardcoded paths to use settings. |
96 |
> |
97 |
> That's a long commit summary ;). Perhaps the “Migrate…” portion |
98 |
> should go into the commit message body, or that could be split out |
99 |
> into a separate commit. |
100 |
|
101 |
will fix |
102 |
|
103 |
> |
104 |
> This might also be a good time to transition from `CatalystError, …` |
105 |
> to `CatalystError(…)` where you're touching lines. |
106 |
> |
107 |
> I'm not sure which versions of Python Catalyst is trying to support, |
108 |
> but I'd be happy to see the beginings of a migration to '{}'.format() |
109 |
> for building strings (vs. the current `'' + ''` concatenation) |
110 |
|
111 |
yeah, there are a ton of those in the code. |
112 |
|
113 |
Since portage is python-2.6+ and python-2.5 is pretty close to being |
114 |
removed from the tree... I intend to make it, 2.6, 2.7, 3.2 + |
115 |
compatible. |
116 |
|
117 |
> |
118 |
> 60919e4 Apply all Matt Turner's has_key() replacement patches |
119 |
> |
120 |
> This looks like a job for `rebase` ;). Cherry-picking will just lead |
121 |
> to redundant commits. |
122 |
> |
123 |
|
124 |
|
125 |
That will be looked after in my rebase to master again. Since I had |
126 |
already made a number of changes in my rewrite branch, I could not apply |
127 |
his commit cleanly without editing. |
128 |
|
129 |
|
130 |
|
131 |
> 7a909b9 cleanup long lines, improve useage() output formatting |
132 |
slightly |
133 |
> |
134 |
> Can we just switch from getopt to argparse (Python ≥2.7)? |
135 |
|
136 |
Yes, we can also add argparse as dep for 2.6 if they want to maintain |
137 |
2.6 compatibility. |
138 |
|
139 |
> |
140 |
> af6e6b7 Initial rearrangement of the python directories |
141 |
> |
142 |
> Hooray! |
143 |
> |
144 |
> 5eeb8b1 new minimal start script |
145 |
> |
146 |
> I think __version__ and __maintainer__ should live in |
147 |
> catalyst/__init__.py. |
148 |
> |
149 |
|
150 |
Can do. The version can also be set for releases easily using some |
151 |
methods from gentoolkit when making the release tarball. The version |
152 |
could then be left as "git" with a partial hash added of the last commit |
153 |
when it was merged with. |
154 |
|
155 |
|
156 |
> 267dbb6 add __init__.py's to modules and arch sub-pkgs |
157 |
> |
158 |
> Added with blank lines? |
159 |
|
160 |
I cheated at the time and just used my editor to save an existing one to |
161 |
different places. So it likely saved it with a blank line. Instead of |
162 |
using a terminal and touch. |
163 |
|
164 |
> |
165 |
> 299e35d update the module loading paths for the new locations |
166 |
> |
167 |
> Can we just drop this import manipulation and use __all__? |
168 |
> |
169 |
> e26de08 chmod +x |
170 |
> |
171 |
> Squash into 5eeb8b1. |
172 |
> |
173 |
yup |
174 |
|
175 |
> a7206bb rename files directory to etc to better reflect the |
176 |
directories contents |
177 |
> |
178 |
> Actually, files/ is also used for other things (e.g. built man pages, |
179 |
> see MAN_PAGES in the Makefile). If we keep the rename to etc/, we |
180 |
> might to just build the man pages under doc/. |
181 |
> |
182 |
Sounds like a plan to me. |
183 |
|
184 |
> da6cbbf rename shell script targets directory to targets.sh so as to |
185 |
not be confused with the new python targets directory |
186 |
> |
187 |
> “so as…” should go in the commit message body to get a shorter |
188 |
> summary. |
189 |
> |
190 |
> I'm not sold on this. Since they are data files intended to be used |
191 |
> by the Python modules, why not move them to catalyst/targets/scripts |
192 |
[1]? |
193 |
|
194 |
I had been re-thinking that change and was thinking of renaming it back |
195 |
to targets now that things have been better rearranged. There is one py |
196 |
file in stage1. It is also easier to do now since it is just one edit |
197 |
and a git mv away. I've removed that directory name from being hard |
198 |
coded in the scripts, so now it just means there is one place to edit. |
199 |
|
200 |
|
201 |
> f9f18be update gitignore |
202 |
> |
203 |
> The Scratch, catalystc, *.geany, and test* entries would appear to be |
204 |
> specific to your local installation and usage. I'd drop them from the |
205 |
> reroll. |
206 |
> |
207 |
|
208 |
They are only for my dev space git repo and me. They will not be part |
209 |
of a final ready to merge branch. But my dev space is also acting as my |
210 |
backup, so I committed them. It makes my git status output cleaner. |
211 |
|
212 |
|
213 |
> d23d96b revert urllib import from commit |
214 |
64c16cae70da13de3c55d8555a2e4c5dcdf2fcad since it is not used anywhere |
215 |
in catalyst |
216 |
> |
217 |
> 64c16cae does a lot more than import urllib, so I think “revert” gives |
218 |
> the wrong impression. I'd remove the import entirely (instead of |
219 |
> commenting it out), and say: |
220 |
> |
221 |
> catalyst/support.py: Remove unused urllib import |
222 |
> |
223 |
> This was introduced in commit |
224 |
> 64c16cae70da13de3c55d8555a2e4c5dcdf2fcad but is no longer used. |
225 |
> |
226 |
|
227 |
Actually urllib was never used. It was added as a fix for a bug. It |
228 |
was not a correct fix, so just masked what was causing the bug. I only |
229 |
commented it out until I could either find what caused the bug or it |
230 |
just didn't return due to other changes. It is often easier to |
231 |
comment/uncomment during testing runs than to remove/re-add code. |
232 |
|
233 |
|
234 |
> ab2c22a comment out some code introduced in commit |
235 |
b3475906d5f51a21ecaf4ff048002a2f44face52 with an undefined variable "s". |
236 |
The code must always be hitting the general except: pass block. Seems |
237 |
useless, if not maybe it'll spit out a true error, so the real problem |
238 |
can be fixed |
239 |
> |
240 |
> Multiple sentences in a commit summary! Also, take advantage of your |
241 |
> version control and just rip the code out instead of commenting it |
242 |
> out. |
243 |
|
244 |
I did that because I did not fully figure out what that whole code block |
245 |
was suppose to do and refactor it all. Leaving it commented out leaves |
246 |
it there for that purpose later which also stands out as a reminder. |
247 |
|
248 |
|
249 |
I looked through b347590 (which is a 408-line monster for |
250 |
> catalyst_support.py), but I'm not clear why Eric was messing with that |
251 |
> code. At any rate, it looks like a good cantidate for replacement |
252 |
> with subprocess.Popen, although see 1b2597e ;). |
253 |
|
254 |
Yeah, there are a lot of os.system() calls throughout the code to |
255 |
replace. |
256 |
|
257 |
> |
258 |
> 95704c7 fix an undefined variable |
259 |
> |
260 |
> Oops ;). I'd mention DESIRED_RLIMIT in the commit message. |
261 |
> |
262 |
|
263 |
yeah. |
264 |
|
265 |
> 1b2597e update todo for a spawn() cleanup. |
266 |
> |
267 |
> +lots |
268 |
> |
269 |
|
270 |
yeah, there are lots of things to add to the todo. I just didn't want |
271 |
to forget about that one. But if others are going to help, keeping that |
272 |
up to date will be more important. |
273 |
|
274 |
|
275 |
> Cheers, |
276 |
> Trevor |
277 |
> |
278 |
> [1]: |
279 |
http://docs.python.org/2/distutils/setupscript.html#installing-package-data |
280 |
> |