incompatible variants

[mahaase]

Feature request to allow incompatible variants.

This problem was also discussed here: https://github.com/BobBuildTool/bob/issues/255 already.

Hallo Jan,

[...]

An deinem Beispiel mit VARIANT a und b als Environment-Variable. Dort ist doch am Ende nicht 100% sicher, dass diese kollidieren. Wenn jetzt z.B. other-recipe eine shared lib „exportiert“ dann könnte VARIANT ja einen unterschiedlichen Pfad definieren, in denen die Artifacts abgelegt werden, oder?

Ich denke immer noch, dass es möglich sein sollte, dass man das erzwingen (per setup in config.yaml?) kann.

>> root/lib-a/lib2
   PACKAGE   dev/dist/lib2/1/workspace
a

>> root/lib-a
   BUILD     dev/build/lib-a/1/workspace
   PACKAGE   dev/dist/lib-a/1/workspace

>> root/lib-b/lib2
   PACKAGE   dev/dist/lib2/2/workspace
b

>> root/lib-b
   BUILD     dev/build/lib-b/1/workspace
   PACKAGE   dev/dist/lib-b/1/workspace

>> root
   BUILD     dev/build/root/1/workspace
   PACKAGE   dev/dist/root/1/workspace

Aus Sicht der Rezepte ist ja bis da hin alles eindeutig. Alle Varianten haben ihre eigenen Verzeichnisse.

Problem ist ja eigentlich „NUR“, dass die „lib2“ mit genau diesem Namen in die Listen (z.B. BOB_DEP_PATHS)

eingetragen wird. HIER kommt es zur Kollision. Aber bob erkennt ja alles schon korrekt, dass es sicht um Varianten handelt etc.

Müsste man den Mechanismus nicht einfach dahin gehend erweitern, dass wir im Falle einer Variante einen PREFIX verpassen…

1/lib2 oder lib-a/lib2 oder so 😊

Natürlich müsste sich der Rezepte-Schreiber drum kümmern, dass eventuelle Ergebnisse im dist sich dann ggf. beim zusammenkopieren nicht überschreiben…

[...]

Mit freundlichen Grüßen / Kind regards

Martin Haase

Serus Martin,

im Prinzip hast du recht. Das ließe sich schon machen. Ich hatte da auch schon mehrfach darüber nachgedacht aber das hat auch ein paar Nachteile:

• Man kann nicht mehr einfach vom Paket-Namen auf das Rezept und anders herum schließen. Das ist durch multiPackages nicht immer eindeutig aber einfach zu finden. Wenn man jetzt unterschiedliche Varianten eines Rezepts unter verschiedenen Namen einbindet wird es verwirrender.

• Was passiert wenn eine dieser "umbenannten" Abhängigkeiten per provideDeps nach oben gereicht wird? Dann wird es schon sehr unübersichtlich herauszufinden wo das Paket jetzt her kam.

• Die Plugin-API würde brechen, da man Recipe.getPackageName() entfernen müsste.

Das sind jetzt alles keine KO-Kriterien aber es hat mich bisher davon abgehalten das zu implementieren. Außerdem gab es bis jetzt immer einen anderen Weg das zu lösen.

Wenn ihr das Feature aber braucht kann man darüber nachdenken. Man muss es ja nicht nehmen...

Ciao, Jan

My last question here is, what means that for the bob user, that the module-name e.g. "lib2" is more complex like "/lib2" (e.g. in BOB_DEP_PATHS). Where do we use this name on the public-interface (e.g. via calling the bob tool)?

BR.

[jkloetzke]

I think the feature will just be about renaming a dependency:

depends:
    - name: foo::bar
      rename: something-else

In this case BOB_DEP_PATHS will have a something-else entry.

[mahaase]

sounds perfect, IF

depends:
    - name: foo::bar
      rename: something-${VAR}

would be possible. :)

[jkloetzke]

Using variable substitution is a different issue IMHO. Currently

depends:
    -"${VAR}"

isn't supported either. But it could be possible.

[mahaase]

fine for me, I added another ticket! :+1:

[mahaase]

how can I help, to force this ticket? :)