incompatible variants

[mahaase]

Feature request to allow incompatible variants.

This problem was also discussed here: #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! 👍

[mahaase]

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