Tagged relations instead of dependencies
Brought to you by:
dirkwallenstein
Menu
▾
▴
#4 Tagged relations instead of dependencies
There are more relations between modules than just build dependencies. As an
example, package repositories could be related to upstream source repositories. They
could exist independently from the normal dependency graph. A source
repository could have multiple packages associated, each identified as such by
a "Relation Tag" (e.g. PACKAGE). Relation tags could have additional
info attached (like a revision), and maybe one relation of many that share the
same tag could be determined dynamically. For example one of the relations
tagged PACKAGE could be selected depending on which version the current source
repository revision is based upon. Patches could be exported to that package
relation target.
The different sorts of build dependencies could be simply tags that
would be used to create a build graph (that could be further truncated
by a tool and sliced with main command line options).
Relations could also exist between two repository groups, and between
a module and a repository group. If such a relation to a repository group
would be tagged as build dependency it would not be necessary to merge
two projects. Such relations would be used instead of nesting.
Tagged relations could be used to allow all sorts of navigation
facilitation. E.g. in a KDE RG move to the Xorg RG that is tagged as
build dependency (Of both projects there could be multiple RG each of
which is prepared for a specific use (input, graphics, etc)).
For the workbench project itself I though it could be used to relate the
main module (x-jhbuild) with unpacked repository groups that are used as
fixtures in test cases (one module relates to many RG tagged with the
FIXTURE tag.)
I think such general relations are ideal for a workbench. Plug-in sets
can implement specific handling on top of them and maybe register their
own tags with descriptions and such.
I thought it would be nice to have a global RG registry that would be
automatically kept up to date by 'xjh' executions. This would be useful when
you want to iterate all RG, for example to extract all your own unpublished
patches for backup. Such a registry could also be used to manage RG relations.
Maybe repository groups could have a project-id like 'xorg', so that RG of a
particular type can be listed, etc.
There could be module selection profiles that can be picked with main
command options. A tool to create such profiles would be required and
profile selection can be persistent. Relation changes could directly
influence profiles (like always include all relations tagged
DEP_OPTIONAL, ignore additions, notify about changes, or require manual
resolution (block) when affected relations of selected modules change).
I think the term "Work Set" would describe such a module selection
profile quite good.
Fork selection is a form of revision selection, so they should be
treated more like branch selection and not through Module Relations
(fork relations aren't arbitrary and forks are basically one of the
same). The active fork should be selected independently from the
configuration and it should be changeable with the plug-in 'spool'. On
the other hand, it is definitely helpful to tie a configuration to the
selected fork. Maybe we can have a module configuration that is shared
between modules of the same type, and configuration sections that apply
to one module only. Maybe such overriding behavior is just a special
form of configuration subsection, like:
[module.xorg-server..mrx/xorg-server]
[module.xorg-server..__main__]
This way the overridden section is directly visible.
That's already another topic, though.
Gotta backpedal a bit. The ideal way to set up a repository group to
work with two projects, is of course to merge their modulesets (project-info).
However, there could be a very small selection of use
cases that involve multiple repository groups (e.g. backup). Plug-ins
working on that level would be very limited in their abilities and for
example not have the environment set.