Gentoo Archives: gentoo-portage-dev

From: Brian Dolbec <dolsen@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] [PATCH] Add --sync-submodule <glsa|news|profiles> (534070)
Date: Wed, 07 Jan 2015 04:54:07
Message-Id: 20150106205350.4ff4ca75.dolsen@gentoo.org
In Reply to: [gentoo-portage-dev] [PATCH] Add --sync-submodule (534070) by Zac Medico
1 On Wed, 31 Dec 2014 00:07:19 -0800
2 Zac Medico <zmedico@g.o> wrote:
3
4 > This adds support for a new --sync-submodule option to both emerge and
5 > emaint. When this option is used with the sync action, only the
6 > selected submodules are synced. Each submodule is referenced using an
7 > abstract identifier, which serves to hide the implementation details
8 > involving the precise locations of specific submodules within each
9 > repository.
10 >
11 > Currently, --sync-submodule has no effect for sync protocols other
12 > than rsync, but the new SyncBase._get_submodule_paths() method will
13 > be useful for implementing support in other SyncBase subclasses.
14 >
15 > X-Gentoo-Bug: 534070
16 > X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=534070
17 > ---
18 >
19 > portage.process.spawn(command, diff --git
20 > a/pym/portage/sync/syncbase.py b/pym/portage/sync/syncbase.py index
21 > 94d4aab..fcde51f 100644 --- a/pym/portage/sync/syncbase.py
22 > +++ b/pym/portage/sync/syncbase.py
23 > @@ -12,6 +12,11 @@ import os
24 > import portage
25 > from portage.util import writemsg_level
26 >
27 > +_SUBMODULE_PATH_MAP = {
28 > + 'glsa': 'metadata/glsa',
29 > + 'news': 'metadata/news',
30 > + 'profiles': 'profiles',
31 > +}
32 >
33 >
34
35 It mostly looks good, but...
36
37 I don't like the idea of hard-coding this in the base class.
38
39 I think this should be configurable per-repo or at least per repo type.
40
41 This patch clears the way for other repo types to have sub-modules, but
42 will they be the same mapping for a git tree with those as
43 sub-modules? Maybe I'm just not following how the system works
44 properly...
45
46 Alternatively...if the above is wrong/not feasible. In the
47 sync/__init__.py you have the choices hard-coded there independently of
48 these definitions above. I would prefer that one get it's options from
49 the other. Since syncbase.py is not gauranteed to be loaded, I would
50 think that the above be declared in the sync module's __init__.py and
51 imported or passed in here. Then the:
52
53 "choices": ("glsa", "news", "profiles"),
54
55 could become:
56
57 "choices": list(_SUBMODULE_PATH_MAP)
58
59 Then there is only one place to edit as options or code change.
60
61
62
63
64
65 --
66 Brian Dolbec <dolsen>

Replies