Zależność Ruby Gemspec: Czy jest możliwe, że istnieje zależność od gałęzi git?

83

Czy możliwe jest posiadanie zależności od gałęzi git wewnątrz mygem.gemspec?

Myślę o czymś podobnym do następującego:

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

... ale to nie działa.

— Luca G. Soave
źródło

Mam ten sam problem, z wyjątkiem tego, że chcę zależności od ścieżki, a nie zależności od git. Czy nie ma sposobu, aby jakoś to obejść? Może przez umieszczenie jakiegoś hakerskiego kodu Ruby w gemspec gdzieś?

— Ajedi32,

44

Nie jest to możliwe i prawdopodobnie nigdy nie będzie, ponieważ dla RubyGems byłoby raczej ciężko, gdyby twórcy gemów wymagali od użytkowników zainstalowania określonego systemu kontroli wersji, aby uzyskać dostęp do klejnotu. Klejnoty powinny być samowystarczalne z minimalną liczbą zależności, aby ludzie mogli ich używać w jak najszerszym zakresie zastosowań.

Jeśli chcesz to zrobić dla swoich własnych projektów wewnętrznych, proponuję użyć Bundlera, który obsługuje to całkiem dobrze.

— gtd
źródło

22

... tak, ale jak mam to zrobić?

— Luca G. Soave

33

Ale co, jeśli twój klejnot ma zostać później włączony do innego klejnotu (np. Foobar_gem)? Kiedy foobar_gem chce rozwiązać zależności w twoim gemie, czy nie będzie wyglądać wyłącznie w pliku gemspec?

— eremzeit

7

Czy kiedykolwiek znalazłeś rozwiązanie tego problemu. Mam dokładnie ten sam problem?

— msaspence

14

@eremzeit & msaspence - ponieważ masz tak wiele głosów za, czuję się zmuszony do odpowiedzi. Nie ma na to rozwiązania, ponieważ robisz to źle . Dobrze jest polegać na repozytorium git dla pojedynczej aplikacji korzystającej z Bundlera, całkowicie błędem jest, aby wydany klejnot polegał na GitHub lub jakimkolwiek innym repozytorium kodu źródłowego. Jeśli wypuszczasz klejnot, wszystkie jego zależności muszą również zostać wydane jako klejnoty. Aby formalny pakiet, taki jak klejnot, polegał na niewydanym kodzie źródłowym, należy postawić wózek przed koniem. Proszę nie próbować tego robić .

— gtd

23

@gtd Tworzenie klejnotu i wypuszczanie klejnotu na rubygemach to dwie odrębne rzeczy. Możliwe, że prywatny nieopublikowany klejnot ma własne prywatne zależności. Wydaje mi się to w porządku. Wydaje się, że RubyGems nie obsługuje tego przypadku użycia, ale nie jestem przekonany, że robi to źle. Po prostu nie ma zbyt wiele, aby to wspierać. Czy się mylę?

— Stephen Crosby

14

EDYTOWAĆ

Według komentatora nie jest to już prawdą. Informacje wstępne zachowane w kontekście historycznym.

Duplikowanie odniesienia do klejnotu w Gemfile i .gemspec wydaje się teraz powodować wyświetlenie ostrzeżenia w programie Bundler, więc ta odpowiedź wydaje się już nie być prawdą.

Nieaktualne informacje

Ten artykuł Yehudy Katza wyjaśnił mi podobne zamieszanie. Mówi się, że do użytku tylko w programowaniu najlepiej jest dodać rzeczy git do pliku gem, ale ten pakiet nadal będzie używał informacji o zależności / wersji z gemspec (wydaje mi się to magiczne, ale ufam Yehuda).

— heartpunk
źródło

3

Co w tym magicznego? Bundler czyta tylko z Gemfile - z wyjątkiem tego, że jeśli gemspectam umieścisz , czyta również z gemspec. Więc kiedy uruchamiasz bundle install, zakładam (ale nie testowałem), że dzieje się tak, że Bundler instaluje klejnot określony w Gemfile. Ponieważ Bundler już go zainstalował, ten klejnot jest dostępny dla tego klejnotu require, niezależnie od tego, że nie pochodzi z repozytorium klejnotów. Żadnej magii, tylko Bundler działa jak zwykle.

— Marnen Laibow-Koser

2

Powielanie odniesienia do klejnotu w Gemfile i .gemspec wydaje się teraz wywoływać ostrzeżenie w programie Bundler, więc ta odpowiedź wydaje się już nie być prawdą ...

— Andy Jones

7

Po prostu próbowałem rozwiązać ten problem. I właśnie wymyśliłem następujące rozwiązanie (którego nie jestem pewien, czy publikujesz swój klejnot, czy masz prawa do redystrybucji tego klejnotu oauth2).

Uruchom to w swoim klejnocie, który wymaga klejnotu oauth2.

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

Jeśli potrzebujesz innej gałęzi niż domyślna

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

W swoim gemspec dodaj to powyżej wymaganej linii wersji

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

Będziesz także musiał dodać wszystkie zależności uruchomieniowe gem oauth2 do swojego gemspec. Nie wymyśliłem jeszcze sposobu na obejście tego.

To właśnie zrobiłem i działa to dla nas, ponieważ nasz klejnot jest wymagany przez git, więc nie jestem pewien, czy zadziałaby to dla klejnotu opublikowanego w rubygemach.

— kwbock
źródło

Dodanie zależności jako modułu podrzędnego jest właściwym rozwiązaniem, jeśli jesteś autorem obu klejnotów i oba są w fazie rozwoju.

— Benjineer

Co ważne, jeśli to zrobisz, może być konieczne użycie: gem 'my_gem', git: 'git@github.com:me/myrepo', submodules: truew aplikacji hosta, jeśli instalujesz z github.

— Joe Edgar,

1

Znalazłem dość proste obejście:

Powiedz, że jesteś w projekcie Pi chcesz użyć samodzielnie wykonanego klejnotu, toolsktóry sam używa klejnotu systemu operacyjnego oauth2.

Jeśli zrobiłeś łatkę w środku oauth2i potrzebujesz tej łatki w swoim klejnocie tools, nie będziesz w stanie naprawić tego problemu w klejnocie zgodnie z zaakceptowaną odpowiedzią .

Możesz jednak doprecyzować żądaną wersję w pliku Gemfile swojego Pprojektu i będzie to wersja używana toolsw czasie wykonywania:

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

Oto mój przykład z życia.

— Ulysse BN
źródło