Parent-child projects

[mosteo]

The old index used child packages as a way to denote a more intimate relation between projects. An example is the adayaml and adayaml.server, and simple_components.*.

Edit I'm currently edging towards using parent-child.toml crate file names, a la gnat sources, for parent.child crates. Nothing major changes in regard to the status quo. If this were to happen:

[ ] Reindex Simple_Components as a collection of child packages.

Original discussion follows:

The main difference and use case for these child projects was that, if they shared the same commit, they weren't checked out as a stand-alone project, but reused the parent checkout. In turn, this required that their corresponding project files were not conflicting (e.g. reusing source files).

In other words, it was a way to split several related components, each one with their own GPR file, in different alire subprojects, without checking out a copy for each one.

Advantages were:

• Possibility of having different dependencies per child
• Reuse of the checkout
• Greater visibility of related components in a large project
• When features were added in later releases, they allowed the previous ones to stand alone (if the project maintainer provided new GPR files for new features, naturally).
• They could still be declared in a single file that contained all child projects (although separate child package files were in the roadmap).

Right now, these kind of projects (e.g., adayaml and adayaml_server) still work but they behave as totally independent projects: they are checked out separately, even being the same commit from the same repository, and the parent-child info does not make into alr.

I can see several approaches about this:

1. Do nothing, and lose these features, if we deem them not important enough.
2. Include a new field in the [general] section to make explicit the relationship: parent = "adayaml", for example, and keep declarations in separate toml files.
3. Something more fancy that allows the declaration of child projects inside a same toml file

Without much thought given, option 2 seems low effort and enough to recover the most interesting advantages.

On a related note, I used the '.' separator because it's more Ada-like. I wonder if we may want to recover that, even if we do nothing else. That leads me to:

4. Use '.' as a especial character in project names that implies the parent-child relationship, and dispense with the parent = "xxx" field to achieve the same result as 2.

I'm liking 4 more right now.

@pmderodat, another one ;-)

[pmderodat]

Hello Alex,

In turn, this required that their corresponding project files were not conflicting (e.g. reusing source files).

I don’t understand this requirement about conflicting files. What problem is there if source files are reused (for instance a common project file to share settings).

• Greater visibility of related components in a large project

How so? Does this visibility come out of the name similarity, or out of some specific processing in Alire (and that case: what processing)?

• When features were added in later releases, they allowed the previous ones to stand alone (if the project maintainer provided new GPR files for new features, naturally).

I also don’t understand this: what’s the relation between features and project files?

[mosteo]

I don’t understand this requirement about conflicting files. What problem is there if source files are reused (for instance a common project file to share settings).

The conflict case I had in mind was related to Ada sources, not GPR projects. The case you say is no problem. Say, your crate packs "project_v1.gpr" and "project_v2.gpr", and they're mutually incompatible (e.g., because they reuse same Ada sources). Then, it makes less sense to separate these into two child (or regular) crates, since they cannot be used simultaneously anyway.

How so? Does this visibility come out of the name similarity, or out of some specific processing in Alire (and that case: what processing)?

Simply because if you see, e.g., adayaml and adayaml.server you know there are at least two GPR files with different features. One could simply have adayaml with two project files within, and you need to either be intimate with the project or do an alr show adayaml to see that it has several GPRs.

I also don’t understand this: what’s the relation between features and project files?

In the adayaml example, the new server feature is provided through a new adayaml-server.gpr file.

At first, I assumed a unique releationship crate <--> repo. Later on, I realized that this was too narrow. This feature in part arose as a way of splicing a repo into several crates, without making them totally unrelated.

In the old Ada syntax you could "override" a release to create a new one, which allowed easy reuse of the general info. See, e.g., https://github.com/alire-project/alire/blob/master/src/oldindex/alire-index-simple_components.ads. Right now we have this within a same crate, with the general and release-specific info. With this feature we could reuse the general part across child crates.

More "historical" musings: at the very beginning I expected to have a single gpr file per crate, so if you depended on a crate, you knew which project file you were going to be using. It soon became evident that this was going to be very limiting, as many people distribute several thematically related GPR files. Simply put, the GPR files introduce a wiggle point, and now one can either distribute a single crate with several GPR files (and give only a single set of dependencies) or several crates, each with its own dependencies, even if they conceptually belong to the same "upstream project".

[mosteo]

After the discussion in #200 this feature won't be coming back (at least not in this shape), so I'm closing it for now.