This only changes the specification without adding any corresponding support to the library (with unit tests!).

The comments shouldn't imply any policies ("this needs to live there and there") or name any specific VCS systems ("this is in dist-git"). Modules can live anywhere and be built by alternative buildsystems. I suggest reading the components section to get the idea but an example would be a modulemd file living on Github with its profile scripts being available on some other website the author trusts and the module being built by a private instance of MBS and... even Copr as the backend, for example :)

What URLs are okay and what are not needs to be decided by the build system, not the format.

Additionally, if you expect these scripts to live in the same repo as the modulemd file, you could just refer to them by their name. If you think they should live in some other VCS repo, consider using a similar scheme to what we already have in the components section.

I'm not sure how the scripts should be distributed; not every VCS system has a public interface the installation/deployment/compose tool can access. Maybe the MBS should inline their contents for you? If so, the comments should explain that because it may affect the script.

How can you run that script without the internet connection (lets say you have ISO generated from modules and you want to install it without the internet connection)? It may be possible for MBS to store the script directly to modulemd, not sure how practical this would be though.. DNF would have to download all those scripts when fetching repo metadata

Why can't you create RPM with this config scripts and include that in particular profile?

Edit: This would probably need to add such rpm to dist-git and therefore to Fedora, so I admit it's not ideal :).

If you want to experiment with modulemd, can't you patch it, build your own version in copr, do the tests and come up with final solution?

@psabata

This only changes the specification without adding any corresponding support to the library (with unit tests!).

I wouldn't do any code changes without ack on design.

I like your other comments. Will update the PR.

@jkaluza

How can you run that script without the internet connection...

This is definitely a good point and the reason I opened this PR -- to get feedback like this.

It may be possible for MBS to store the script directly to modulemd, not sure how practical this would be though.. DNF would have to download all those scripts when fetching repo metadata

That is the reason I made the script remote. Expanding repodata is probably something which everybody dislikes.

Why can't you create RPM with this config scripts and include that in particular profile?

As you said, for proof of concept, this is way too much work. It would be great if we converged to a variant of this solution.

If you want to experiment with modulemd, can't you patch it, build your own version in copr, do the tests and come up with final solution?

It's impossible to come up with final solution now, when all the pieces are moving constantly. I also don't want to figure out final solution just to realize it doesn't scale/work/everyone hates it -- I want to iterate quickly and explore different solutions. This is the first, most simplest one.

Anyway, thank you gentlemen for feedback: very valuable.

Updated.

Changed it to link to the script via path, and optionally even set different repository (and ref).

This iteration also contains code and basic tests.

Will squash commits before merge.

For future reference: We agreed not to do this.