Feature #1684: Implement "includes" relation for distributions - Automated Build Generator - Open Source Collaboration Platform

Feature #1684

Implement "includes" relation for distributions

Added by J. Moringen over 9 years ago. Updated about 4 years ago.

Status:

Resolved

Start date:

12/11/2013

Priority:

Normal

Due date:

Assignee:

J. Moringen

% Done:

100%

Category:

Data Model

Target version:

1.0

Description

Ingmar's report

Distributionen, wie z.B. die RSB-0.9 Distribution, sollen in anderen Distributionen als Bestandteil angegeben werden können. Ähnlich wie bereits Projekte.

Duplicate

Is there a way to define a "sub-distribution" that can be included in your distribution?
E.g. the flobi simulation needs a set of ~8 projects. Everytime we define a distribution that uses that flobi sim we have to copy and paste these 8 projects.
When we add a dependency we have to do that on all packages...
It would be really nice to have such a feature.

Associated revisions

Revision 832e17a7
Added by J. Moringen about 4 years ago

Model changes for distribution includes in src/model/project/classes-spec.lisp

New concepts {[resolved-]project,distribution}-include represent
inclusion of distributions and projects with parameters.

A new `direct-includes' slot stores the distributions included by
the a given one.

The `version' slot is now called `direct-versions' since project
version can now also be included indirectly through an included
distribution.

refs #1684

src/commands/functions-input.lisp (header): updated copyright
(locate-projects): adapted to model changes
(load-project/versioned): likewise
(load-projects/versioned): likewise
(resolve-project-versions): likewise
src/commands/command-generate.lisp (header): updated copyright
(generate-analyze): adapted to model changes
src/commands/package.lisp (header): updated copyright
(package jenkins.project.commands): added shadowed symbol version
src/model/project/classes-model.lisp (header): updated copyright
(include-context): new class; include context for project versions
(version::context): new slot; stores include context
(lookup version t): look in specification, include context, parent,
context distribution and toplevel distribution
src/model/project/classes-spec.lisp (header): updated copyright
(distribution-include): new class; represents an included
distribution
(print-items append distribution-include): new method; print items
(project-include): new class; represents an unresolved project
version include
(print-items append project-include): new method; print items
(resolved-project-include): new class; represents a resolved project
version include
(print-items append resolved-project-include): new method; print
items
(distribution-spec::direct-includes): new slots; stores included
distributions
(distribution-spec::direct-versions): renamed versions ->
direct-versions
(versions distribution-spec): new method; collect and return direct
and transitively contained versions
(instantiate distribution-spec): instantiate transitively contained
versions with appropriate include contexts
(instantiate version-spec): accept include context
src/model/project/package.lisp (header): updated copyright
(package jenkins.model.project): added exported symbols
direct-{includes,versions}, versions distribution-include,
distribution, project-include, project, version,
resolved-project-include and context

Revision d13cf6fb
Added by J. Moringen about 4 years ago

Syntax for distribution includes in src/model/project/concrete-syntax/yaml.lisp

refs #1684

src/model/project/concrete-syntax/yaml.lisp (parse-distribution-include-spec):
new function; parse the different forms of distribution include
specification
(define-yaml-load one-distribution): renamed distribution ->
one-distribution; accept include key in distribution recipes
(distributions): new variable; already loaded distributions
(find-distribution): new function; find a loaded distribution
(ensure-distribution): new function; find a distribution or call a
thunk
(distribution-load-stack): new variable; stack of distributions
currently being loaded
(find-or-load-distribution): new function; find or load a
distribution
(resolve-distribution-dependency): new function; load a distribution
from a file if necessary

Revision 19f5f473
Added by J. Moringen about 4 years ago

Avoid inheritance of distribution-name in src/model/project/classes-model.lisp

Projects will only ever "see" the value of the distribution-name
variable in the "outermost" distribution, i.e. the one specified on
the commandline.

refs #1684

src/model/variables/schema.lisp (header): updated copyright
(inheritance-mode): added value :outermost-only
src/model/schema.lisp (header): updated copyright
(define-variable :distribution-name): new variable; name of the
distribution with :outermost-only inheritance
src/model/project/classes-model.lisp (lookup version t): don't
inherit variables specified as :outermost-only

Revision e536cafe
Added by J. Moringen about 4 years ago

Added enhancement entry in changes.sexp

fixes #1684

changes.sexp (release 0.26): added enhancement entry

History

#1 Updated by J. Moringen almost 9 years ago

Target version changed from 0.3 to 0.4

#2 Updated by J. Moringen over 8 years ago

Description updated (diff)

#3 Updated by J. Moringen about 8 years ago

Target version changed from 0.4 to 0.5

#4 Updated by S. Meyer zu Borgsen about 8 years ago

Could it be a first simple solution to simply join multiple "verions"-lists?

#5 Updated by J. Moringen about 8 years ago

S. Meyer zu Borgsen wrote:

Could it be a first simple solution to simply join multiple "verions"-lists?

This really depends on the mid- and maybe long-term strategy for this project. There are three major possibilities:

Implement the feature in the current architecture and code base (as you suggest). I did this in a feature branch but it stretches the current architecture far beyond its original scope.
Implement the feature in the new architecture loosely based on the current code base. I did this in a feature branch as well and it worked quite well. The new architecture solves several other problems as well. For example, distribution version are defined in a single recipe and share most of the definitions like project versions currently already do. As another example, branches and tags are no longer mandatory in projects; instead, distributions can request arbitrary branches, tags or commit without changes to project recipes.
Rewrite the project according to the "new architecture" mentioned in 2) or some other architecture. This would of course allow going about the inclusion feature in the same way as in 2) or in some other smart way.

The complications, potential problems and short-term character involved in 1. probably make it not worth the effort.

We attempted to decide between 2. and 3. several times but each time failed to organize the respective meeting. No matter how we decide between 2. and 3., significant effort will be required and the respectively resulting new generator will not be a drop-in replacement, thus another migration will be necessary in addition.

As a result, I think this feature will take some time.

#6 Updated by S. Wrede about 8 years ago

J. Moringen wrote:

We attempted to decide between 2. and 3. several times but each time failed to organize the respective meeting.

Which was also due to holiday of key personnel involved... ;-)

No matter how we decide between 2. and 3., significant effort will be required and the respectively resulting new generator will
not be a drop-in replacement, thus another migration will be necessary in addition.

This is true. However, this feature may be ranked relatively high on the roadmap for the new build gen architecture / implementation strategy as the lack of it currently impedes scalability of the development process.