1 |
On 04/24/2016 02:45 PM, Zac Medico wrote: |
2 |
> On 04/24/2016 01:00 AM, Brian Dolbec wrote: |
3 |
>> On Sun, 24 Apr 2016 08:15:56 +0200 |
4 |
>> Michał Górny <mgorny@g.o> wrote: |
5 |
>> |
6 |
>>> On Sat, 23 Apr 2016 16:57:21 -0700 |
7 |
>>> Zac Medico <zmedico@g.o> wrote: |
8 |
>>> |
9 |
>>>> Fix ArchChecks to not mix arches of ebuilds together, so that |
10 |
>>>> errors are only reported for those arches that the ebuild has |
11 |
>>>> keywords for. |
12 |
>>>> --- |
13 |
>>>> Applies to the *repoman* branch. |
14 |
>>>> |
15 |
>>>> pym/repoman/modules/scan/arches/arches.py | 2 +- |
16 |
>>>> 1 file changed, 1 insertion(+), 1 deletion(-) |
17 |
>>>> |
18 |
>>>> diff --git a/pym/repoman/modules/scan/arches/arches.py |
19 |
>>>> b/pym/repoman/modules/scan/arches/arches.py index 4df25a8..6e1c17d |
20 |
>>>> 100644 --- a/pym/repoman/modules/scan/arches/arches.py |
21 |
>>>> +++ b/pym/repoman/modules/scan/arches/arches.py |
22 |
>>>> @@ -69,7 +69,7 @@ class ArchChecks(ScanBase): |
23 |
>>>> arches.add(('**', '**', ('**',))) |
24 |
>>>> # update the dynamic data |
25 |
>>>> dyn_arches = kwargs.get('arches') |
26 |
>>>> - #dyn_arches.clear() |
27 |
>>>> + dyn_arches.clear() |
28 |
>>>> dyn_arches.update(arches) |
29 |
>>> |
30 |
>>> Is that some crazy way of replacing contents of an existing dict? May |
31 |
>>> be worth a comment since the code looks suspicious, at least. |
32 |
>>> |
33 |
>> |
34 |
>> It was an interim step so that modules didn't pass back |
35 |
>> arbitrary data to be re-used by other modules after it. This way |
36 |
>> maintains the data pointer to the set (not dict) object in the calling |
37 |
>> function. Just assigning it a new set doesn't set the 'arches' pointer |
38 |
>> in the calling function so that it can pass that data along to other |
39 |
>> modules. |
40 |
> |
41 |
> I feel like the plugin structure has lead to decoupling of things that |
42 |
> really should be coupled. For example, the code in the ArchChecks could |
43 |
> be a function that's called by the ProfileDependsChecks plugin, given |
44 |
> that ProfileDependsChecks seems to be the only consumer of this data. |
45 |
|
46 |
We'll have to go through all of the plugins and look for other things |
47 |
that have too aggressively decoupled. The fact Scanner._scan_ebuilds |
48 |
calls plugins in a hardcoded order is troubling. It means that there may |
49 |
be coupling between plugins that makes the order matter, yet this |
50 |
coupling is hidden and non-trivial to discover. If we couple more things |
51 |
together where appropriate (like ArchChecks and ProfileDependsChecks), |
52 |
then it will make the system easier for a person to reason about. |
53 |
-- |
54 |
Thanks, |
55 |
Zac |