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