Ruby Gemspec-Abhängigkeit: Ist eine Git-Verzweigungsabhängigkeit möglich?


81

Ist es möglich, eine git-Verzweigungsabhängigkeit in mygem.gemspec zu haben?

Ich denke etwas Ähnliches wie das Folgende:

gem.add_runtime_dependency 'oauth2', :git => 'git@github.com:lgs/oauth2.git'

... aber es funktioniert nicht.


Ich habe das gleiche Problem, außer dass ich eine Pfadabhängigkeit möchte, keine Git-Abhängigkeit. Gibt es nicht eine Möglichkeit, das irgendwie zu umgehen? Vielleicht, indem Sie irgendwo einen hackigen Ruby-Code in die Gemspec stecken?
Ajedi32

Antworten:


44

Dies ist nicht möglich und wird es wahrscheinlich auch nie sein, da es für RubyGems ziemlich schwierig wäre, Gem-Entwicklern die Möglichkeit zu geben, von Benutzern die Installation eines bestimmten Versionskontrollsystems für den Zugriff auf ein Gem zu verlangen. Edelsteine ​​sollten in sich geschlossen sein und eine minimale Anzahl von Abhängigkeiten aufweisen, damit die Benutzer sie in einem möglichst breiten Anwendungsbereich verwenden können.

Wenn Sie dies für Ihre eigenen internen Projekte tun möchten, würde ich vorschlagen, Bundler zu verwenden, der dies recht gut unterstützt.


21
... ja, aber wie kann ich das machen?
Luca G. Soave

33
Aber was ist, wenn Ihr Edelstein später in einen anderen Edelstein aufgenommen werden soll (z. B. foobar_gem)? Wenn foobar_gem Abhängigkeiten in Ihrem Edelstein auflösen möchte, wird es dann nicht ausschließlich in der gemspec-Datei angezeigt?
Eremzeit

7
Haben Sie jemals eine Lösung dafür gefunden? Ich habe genau das gleiche Problem.
Msaspence

14
@eremzeit & msaspence - da du so viele positive Stimmen hast, fühle ich mich gezwungen zu antworten. Es gibt keine Lösung dafür, weil Sie es falsch machen . Es ist in Ordnung, sich für eine einzelne Anwendung mit Bundler auf ein Git-Repo zu verlassen. Es ist völlig falsch, wenn ein veröffentlichtes Juwel von GitHub oder einem anderen Quellcode-Repository abhängt. Wenn Sie einen Edelstein freigeben, müssen alle seine Abhängigkeiten auch als Edelsteine ​​freigegeben werden. Um ein formelles Paket wie einen Edelstein auf unveröffentlichten Quellcode zu setzen, muss der Wagen vor das Pferd gestellt werden. Bitte versuchen Sie dies nicht .
GTD

22
@gtd Das Erstellen eines Edelsteins und das Freigeben eines Edelsteins auf Rubygems sind zwei verschiedene Dinge. Es ist möglich, dass ein privates unveröffentlichtes Juwel eigene private Abhängigkeiten hat. Das scheint mir in Ordnung zu sein. RubyGems scheint diesem Anwendungsfall nicht gerecht zu werden, aber ich bin nicht davon überzeugt, dass dies falsch ist. Es gibt einfach nicht viel zu unterstützen. Liege ich falsch?
Stephen Crosby

13

BEARBEITEN

Laut einem Kommentator ist dies nicht mehr wahr. Vorherige Informationen für den historischen Kontext aufbewahrt.

Das Duplizieren des Verweises auf einen Edelstein in Gemfile und .gemspec scheint nun eine Warnmeldung in Bundler auszulösen, sodass diese Antwort nicht mehr wahr zu sein scheint.

Veraltete Informationen

Dieser Artikel von Yehuda Katz hat ähnliche Verwirrung für mich beseitigt. Es heißt, dass es für die Verwendung nur in der Entwicklung am besten ist, das Git-Zeug in die Gem-Datei einzufügen, aber dieser Bundler verwendet weiterhin die Abhängigkeits- / Versionsinformationen aus der Gem-Spezifikation (scheint mir magisch, aber ich vertraue Yehuda).


3
Was ist daran so magisch? Bundler liest nur aus der Gemfile - außer dass, wenn Sie gemspecdort eingeben, es auch aus der Gemspec liest. Wenn Sie also ausführen bundle install, gehe ich davon aus (aber noch nicht getestet), dass Bundler das in der Gemfile angegebene Gem installiert. Da Bundler es bereits installiert hat, steht dieser Edelstein für den Edelstein zur Verfügung require, unabhängig davon, dass er nicht aus einem Edelstein-Repository stammt. Keine Magie, nur Bundler arbeitet wie gewohnt.
Marnen Laibow-Koser

2
Das Duplizieren des Verweises auf einen Edelstein in Gemfile und .gemspec scheint nun eine Warnmeldung in Bundler auszulösen, sodass diese Antwort nicht mehr wahr zu sein scheint ...
Andy Jones

7

Ich habe nur versucht, dieses Problem auch herauszufinden. Und ich habe gerade die folgende Lösung gefunden (bei der ich nicht sicher bin, ob Sie Ihren Edelstein veröffentlichen oder das Recht haben, diesen Edelstein oauth2 weiterzugeben).

Führen Sie dies in Ihrem Edelstein aus, für den ein oauth2-Edelstein erforderlich ist.

git submodule add git@github.com:lgs/oauth2.git lib/oauth2

Wenn Sie einen anderen Zweig als den Standardzweig benötigen

cd lib/oauth2 && git checkout <branchname_or_ref>
cd .. && git add lib/oauth2
git commit -m "adding outh2 submodule"

Fügen Sie dies in Ihrer Gemspec über Ihrer gewünschten Versionszeile hinzu

$:.push File.expand_path('../lib/oauth2/lib', __FILE__)

Außerdem müssen Sie alle Laufzeitabhängigkeiten des oauth2-Edelsteins zu Ihrer gemspec hinzufügen. Ich habe noch keinen Weg gefunden, dies zu umgehen.

Dies ist, was ich getan habe, und es funktioniert für uns, weil unser Edelstein über Git benötigt wird, daher bin ich mir nicht sicher, ob dies für einen von Rubygems veröffentlichten Edelstein funktionieren würde.


Das Hinzufügen der Abhängigkeit als Submodul ist die richtige Lösung, wenn Sie beide Edelsteine ​​erstellt haben und sich beide in der aktiven Entwicklung befinden.
Benjineer

Wenn Sie dies tun, müssen Sie möglicherweise gem 'my_gem', git: 'git@github.com:me/myrepo', submodules: trueFolgendes verwenden: in Ihrer Hostanwendung, wenn Sie von github installieren.
Joe Edgar

1

Ich fand eine Problemumgehung ziemlich einfach:

Angenommen, Sie befinden sich in einem Projekt Pund möchten das selbst erstellte Juwel verwenden, toolsdas selbst ein Betriebssystem-Juwel verwendet oauth2.

Wenn Sie einen Patch oauth2in Ihrem Edelstein erstellt haben und diesen Patch in Ihrem Edelstein benötigen, toolskönnen Sie dieses Problem im Edelstein gemäß der akzeptierten Antwort nicht beheben .

Sie können jedoch die gewünschte Version in der Gemfile Ihres PProjekts angeben. Dies ist die Version, die toolszur Laufzeit verwendet wird:

gem 'oauth2', github: 'lgs/oauth2'

Hier ist ein Beispiel aus meinem wirklichen Leben.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.