Multiple dependencies, same package with different environments

[ThomasFeher]

We would like to do the following:

# file my.yaml
multiPackage:
    app:
        buildVars: [VAR]
        buildScript: "# build here"
        packageScript: "# package here"
    build_all:
        root: True
        depends:
            -
              name: my-app
              environment:
                  VAR: "1"
            -
              name: my-app
              environment:
                  VAR: "2"
        buildScript: "# package all variants"

But this is currently not supported by Bob:
Parse error: Multiple incompatible dependencies to package: my-app

A workaround we found, was to introduce intermediate packages. But they contain some boiler plate to forward the build results.

# file my.yaml
multiPackage:
    app:
        buildVars: [VAR]
        buildScript: "# build here"
        packageScript: "# package here"
    app_var1:
        environment:
            VAR: "1"
        depends: [my-app]
        buildScript: "# boilerplate to symlink results from app"
        packageScript: "# boilerplate to symlink results from build step"
    app_var2:
        environment:
            VAR: "2"
        depends: [my-app]
        buildScript: "# boilerplate to symlink results from app"
        packageScript: "# boilerplate to symlink results from build step"
    build_all:
        root: True
        depends:
            - my-app_var1
            - my-app_var2
        buildScript: "# package all variants"

Is there any other option on how to use a certain package as dependency multiple times?

Use-cases are for example:

• building all variants of a certain package as part of the release process
• building the same application for multiple cores of a processor

[jkloetzke]

But this is currently not supported by Bob:
Parse error: Multiple incompatible dependencies to package: my-app

This cannot be supported. The underlying problem is that you cannot address the individual packages anymore because they have the same name. The BOB_DEP_PATHS associative array would also not work because there are two values for the same key. Additionally it acts as a safeguard for provided dependencies to match.

A workaround we found, was to introduce intermediate packages. But they contain some boiler plate to forward the build results.

Utilizing anonymous multiPackages you could write it as follows:

# file my.yaml
multiPackage:
    "":
        buildVars: [VAR]
        buildScript: "# build here"
        packageScript: "# package here"

        multiPackage:
            app_var1:
                environment:
                    VAR: "1"
            app_var2:
                environment:
                    VAR: "2"
    build_all:
        root: True
        depends:
            - my-app_var1
            - my-app_var2
        buildScript: "# package all variants"

Is there any other option on how to use a certain package as dependency multiple times?

I'm afraid there is no other option. Bob's structure requires that different variants of a recipe must have distinct names if they are used as input for the same package.

Use-cases are for example:

building all variants of a certain package as part of the release process
building the same application for multiple cores of a processor

As long as the different cores have separate images it should be no problem because the image would be one layer of indirection. Otherwise I would propose a schema like above.

[ThomasFeher]

That solution works fine for us. Thank you very much!

One idea we had, would be to add a field alias to avoid name conflicts. With this improvement the original example would look like:

# file my.yaml
multiPackage:
    app:
        buildVars: [VAR]
        buildScript: "# build here"
        packageScript: "# package here"
    build_all:
        root: True
        depends:
            -
              name: my-app
              environment:
                  VAR: "1"
              alias: app_var1
            -
              name: my-app
              environment:
                  VAR: "2"
              alias: app_var2
        buildScript: "# package all variants"

It would be a bit more intuitive, at least for me, but in the end it's the same as your solution using the anonymous multipackage.

[jkloetzke]

You're welcome.

In fact I was thinking hard about adding such a "rename" feature for a long time. In the end I was reluctant to add it so far because you will end with package names that you won't find directly in the recipes. And until now there was always another way to solve it. 😉