Stellen Sie sich eine Rack-Anwendung vor, die beim Start Instanzen anderer Ruby-Anwendungen erstellt und Routen diesen Anwendungen zuordnet. Diese Anwendung hat eine Rack-Abhängigkeit von 1.2.2.
Stellen Sie sich nun vor, wir entwickeln eine Unteranwendung, die von dieser Anwendung ausgeführt wird. Es hat eine Sinatra-Abhängigkeit von 1.2.6 und verwendet Bundler. Es ist gemfile ist unfruchtbar:
%Vor% Leider, wenn wir bundle install diese Unteranwendung, Bundler, ohne Kenntnis der Rack 1.2.2 Abhängigkeit von der übergeordneten Anwendung, installiert die aktuellste Version von Rack, die mit Sinatra 1.2.6 kompatibel ist: derzeit 1.3.2. Unser Gemfile.lock wird sein:
Wenn wir versuchen, die Hauptanwendung zu starten (die unsere Unteranwendung startet), erhalten wir:
You have already activated rack 1.2.2, but your Gemfile requires rack 1.3.2. Consider using bundle exec. (Gem::LoadError)
Was ist der richtige Weg, um mit dieser Situation umzugehen? Ja, wir könnten explizit Rack 1.2.2 anfordern, aber wir würden effektiv eine Abhängigkeit von einer Abhängigkeit angeben. Ich würde mir vorstellen, dass die Elternanwendung im Idealfall ein Juwel wäre, das unsere Unteranwendung erfordern würde, aber in dieser Situation haben wir nicht die Möglichkeit, dies zu tun.
Ihr "Haupt" -Prozess sollte bundle exec verwenden, um die Unterprozesse zu starten, genau wie die Fehlermeldung es empfiehlt.
Dadurch wird die neue App innerhalb ihres eigenen Gemfile -Bundlekontextes und nicht des globalen Gem-Kontexts gestartet. Daher wird die neue App mit Rack 1.3.2 oder höher, not Rack 1.2.2.