Publikacja gem-a na GitHub-ie

Jakie założenia należy spełnić oraz co ewentualnie wykonać, aby opublikować gem-a na GitHub-ie, aby można było go zainstalować poleceniem “gem install nazwa_gema”?

Przy tworzeniu gema wspierałem się narzędziem “jeweler”, który wygenerował odpowiednią strukturę gem-a, utworzył repozytorium na GitHub-ie oraz wysłał zawartość projektu. Jednak nie mogłem zainstalować tego gema, gdyż nie mógł go znaleźć. Próbowałem zainstalować poprzez “gem install project” oraz “gem install user-project” i z podaniem źródła, ale efekt był ten sam - gem nie został znaleziony. Dodam, że pliki Rakefile i project.gemspec miałem poprawne.

Githubowi nic do publikowania gemów. http://help.rubygems.org/faqs/gemcutter/publishing-your-own-rubygem

Rzuć okiem na mój wpis dotyczący Gemcuttera http://www.apohllo.pl/blog jeśli wolisz po polsku :slight_smile:

No nie do konca tak “nic do publikowania gemow”. Github przez dlozszy czas budowal automatycznie i publikowal gemy, ale to juz przeszlosc.

Dodatkowo dodam, że bundler potrafi pobrać źródło gema prosto z githuba i zbudować go lokalnie - z pominięciem gemcuttera.

Dlatego napisałem, że nic nie ma (czas teraźniejszy). Tego wątku o przeszłości nie chciałem rozwijać bo uważam ten pomysł z gemami login-nazwa za bardzo zły pomysł, ale że to już przeszłość to nie zaczynałem wątku.

Eee, niby czemu login-nazwa byly zle? Pare razy form byl ciekawszy od oryginalnego gema. Teraz trzeba albo bundler albo sie meczyc z budowaniem lokalnym.

@grk bo tylko burdel się robił. Jak chcesz cos poprawic, dopisac w gemie to forkujesz, piszesz, pull request. Wyobraź sobie, że byłoby 156 wersji railsow, seban-rails, radarek-rails i jedne w wersji 1.2.5.678, drugie 2.4.5

To dlaczego wycofali się z tego? To było głupie. Gemy miały prefix, ale i tak ładowało je się bez prefixu. Trzeba było bawić się w gem “cośtam”. Potem można było pogubić się jaki gem ładuje itp. Generalnie był burdel. Podobnie jak z forkami (http://radarek.jogger.pl/2010/04/19/forkuj-z-glowa/ :D). Z tego co pamiętam to github budował automatycznie gem jeśli był w projekcie poprawny gemspec. Wystarczyło więc zrobić fork, żeby pojawił się nowy gem z prefixem loginu. Potem ja instalowałem (czasem świadomie, czasem nie) taki gem, a okazywało się, że nie jest w ogóle rozwijany itp. Wiem, że nie wszyscy podzielają moje zdanie, ale wystarczy wyjść poza freelancerski świat (w którym każdy ma czas i chęci żeby śledzi dokładnie prawie każde zmiany w interesujących go gemach/forkach), żeby cenić prostotę i przejrzystość.

Według mnie może być i 1000 forków i prefixowanych gemów i według mnie niewiele to zmienia. Jak nie masz czasu na zabawy to instalujesz oficjalnego gema, jak masz czas to możesz przejrzeć czy ktoś ma coś sensownego u siebie czego akurat potrzebujesz. Jeżeli autorowi forka nie zależy na tym, żeby ktoś zaaplikował jego zmiany, które Ci są potrzebne, a nie chcesz używać prefixowanego gema, to zawsze sam możesz je spróbować przepchnąć do oficjalnego projektu. Nie widzę z tym żadnych probemów. :slight_smile:

Ale te forki niech sobie będą. Jak ktoś będzie zainteresowany to sobie ściągnie, zbuduje i zainstaluje. Tylko czemu mają zaśmiecać główne repozytorium gemów? Dlaczego przy gem search -r “foo” mam dostawać mnóstwo niepotrzebnych śmieci (nie mówiąc już o sytuacji gdy gem xxx mógł zostać zainstalowany także z githuba jako yyy-xxx - niepotrzebna duplikacja)? Dlaczego inni nie powielili tego pomysłu? (np. CPAN, paczki linuksowe itp) I przede wszystkim: dlaczego github wycofał się z tego pomysłu? Drogus, jesteś jedną z osób które aktywnie uczestniczą w community i śledzą wszelkie nowinki. Dla takich osób jak Ty nie jest problemem taka sytuacja bo Ty szybko zorientujesz się co jest oficjalnym forkiem a co nie. Pamiętajcie jednak o innych. I wcale nie chodzi mi o tzw “źółtodziobów”, ale choćby ludzi którzy chcą przejść z innej technologii i zastają trochę dziwną sytuację.

Pamiętam o innych i dalej nie widzę problemu :slight_smile:

Jeżeli ktoś jest żółtodziobem, to instaluje gemy według tego co przeczyta w książkach i tutorialach. Dlatego nawet jeżeli nie wie, że gemy suffixowane pochodzą najprawdopodobniej z customowych forków, to i tak jak napiszą mu: “zainstaluj gem rails komendą gem install rails”, to tak właśnie to zrobi.

Gem np. drogus-rails ma inną nazwę niż oficjana wersja i naprawdę nie sądzę, żeby ktoś go chciał instalować. Tak samo mógłbyś powiedzieć, że np. gem rspec-rails ma mylącą nazwę i ktoś może go pomylić z railsami :wink:

Ogólnie nie jestem zwolennikiem wrzucania każdego forka jako gema z prefixem, ale jeżeli mam do rozwiązania jakiś problem i jest to wygodniejsze i szybsze dla mnie rozwiązanie, to nie będę się zastanawiał nad tym czy ktoś zobaczy mojego gema przy gem search -r. Teraz jest bundler, więc w 90% przypadków można wczytać gema z repozytorium gita, ale nie zawsze mamy dostęp do bundlera i nie zawsze możemy wczytywać gem z repozytorium. Dlatego czasami wygodniej jest po prostu wrzucić gema drogus-costam na gemcuttera i mieć spokój.

Chłopaki, zgubiłem się i nie ogarniam: o co właściwie się kłócicie? Radarkowi podoba się posunięcie Githuba z zaprzestaniem budowania gemów, Drogomir nie ma problemu z ekosystemem gemów autor-nazwa, ale jakoś nie widzę gdzie te dwa stanowiska są przeciwstawne?

W takim razie chyba źle zrozumiałem posta radarka :slight_smile:

Myślałem, że tak jak z tym forkowaniem nie podoba mu się wrzucanie na gemcuttera swoich wersji gemów z prefixem. Sam pomysł automatycznego budowania gemów na githubie mi też się nie podoba. Co innego jak od czasu do czasu ktoś potrzebuje wrzucić na gemcuttera swojego sforkowanego gema z przedrostkiem (tak jak na przykład jest to opisane tutaj: http://drnicwilliams.com/2009/11/04/hacking-someones-gem-with-github-and-gemcutter/)