Jak poradzić sobie z zewnętrznymi zależnościami w projekcie typu open source?

23

Kiedy ktoś pisze projekt open source i używa Google Code lub GitHub i chce korzystać z biblioteki takiej jak Lua, jak należy to zrobić?

  • Czy zależność powinna być zawarta w repozytorium?
  • Czy zależność powinna być budowana z tego samego skryptu kompilacji, co z pozostałej części projektu, czy z oddzielnego skryptu kompilacji?

Ponieważ biblioteka nie wymaga instalacji przed kompilacją.

open-source version-control dependencies po prawej stronie
źródło

Odpowiedzi:

10

Gorąco polecam przeczytanie dokumentacji Git na temat podmodułów ; rozwiązuje ten problem, zakładając, że wszystkie źródła używają Git. Jeśli nie, zawsze możesz skonfigurować repozytorium git w celu integracji. Wysiłek jest trywialny, a wypłata znacząca.

Bryan Agee
źródło
1
Podmoduły to raczej słaba implementacja zarządzania zależnościami zarówno we wspólnej, jak i w Git. Przynajmniej git poddrzewo jest o wiele lepszą iteracją
Lazy Badger
4
-1 Proszę podać szczegóły linku w swojej odpowiedzi, w przeciwnym razie odpowiedź jest bezużyteczna, gdy link zniknie - jak ma to miejsce obecnie. Niestety, nie mam jeszcze przedstawiciela, aby głosować
Precastic
@Precastic: Jeśli przejrzysz tekst linku, przejdziesz bezpośrednio do nowej strony; Nie jestem pewien, o ile bardziej może to być pouczające.
Bryan Agee
1
Przeczytaj stackoverflow.com/help/how-to-answer - w szczególności sekcję zatytułowaną „Podaj kontekst dla linków” (cytat: „Zawsze cytuj najistotniejszą część ważnego linku, na wypadek gdyby strona docelowa była nieosiągalna lub pozostała na stałe offline . ")
Precastic
17

Czy zależność powinna być zawarta w repozytorium?

Myślę, że zależności powinny być zawsze zawarte w repozytorium, o ile ich uwzględnienie nie narusza żadnych warunków użytkowania. Niewiele rzeczy jest bardziej denerwujących niż konieczność ręcznego znajdowania odpowiednich wersji odpowiednich zależności, zanim będzie można zbudować kompilację. Oczywiście jest to łatwe, gdy masz zautomatyzowane narzędzia, które mogą to zrobić za Ciebie, które mogą znaleźć i pobrać odpowiednią zależność, ale co zrobić, jeśli nie jesteś w tej chwili podłączony do Internetu lub serwer jest wyłączony lub projekt zależności został całkowicie wycofany i przejął tryb offline? Zawsze uwzględniaj zależności, jeśli to możliwe.

Czy zależność powinna być budowana z tego samego skryptu kompilacji, co z pozostałej części projektu, czy z oddzielnego skryptu kompilacji?

O ile nie ma dobrego powodu, aby kompilować ze źródła, używaj wstępnie skompilowanych wersji.

A dlaczego nie podać opcji w skrypcie kompilacji? Prosty przełącznik do wyboru, czy zależności powinny być również kompilowane, czy nie. Jeśli użytkownik zdecyduje się również na kompilację zależności, po prostu wywołaj własne skrypty budowania ze skryptu kompilacji produktu. Użytkownik może więc ręcznie wywoływać skrypty kompilacji zależności lub wybrać utworzenie pełnej kompilacji wszystkiego. Ale po prostu dostarczałbym zależności jako pliki binarne, jeśli nie ma dobrego powodu, aby je kompilować ze źródeł. Myślę, że w świecie Open Source niektóre licencje wymagają rozpowszechniania źródeł wraz z produktem, ale to nie znaczy, że nie można ich wstępnie skompilować.

W skrócie: Zapewnij cały autonomiczny, działający pakiet, jeśli to możliwe. Zapewni to największą wygodę użytkownikom.

Sokół
źródło
1
@tdammers: Wiem, jeśli instalujesz oprogramowanie w systemie Linux, menedżer pakietów wykona za ciebie całą pracę. Ale to wymaga połączenia z Internetem, a pakiet musi mieć określony format, a ja wyraźnie stwierdziłem, że narzędzia automatyzacji mogą w tym pomóc. Nie można na przykład używać takiego systemu do narzędzi open source .NET. Jeśli spojrzysz na narzędzia sourceforge, takie jak NHibernate lub Castle Windsor, zobaczysz, że wszystkie zależności są uwzględnione jako pliki binarne. I to jedyna rozsądna rzecz do zrobienia.
Falcon
1
@tdammers: Zbiegiem okoliczności, muszę dziś zainstalować tutaj pakiet OpenOffice SDK na komputerze z systemem Linux. Ponieważ zestawu SDK nie można zainstalować za pomocą menedżera pakietów, pobrałem RPM ze strony internetowej. Jak myślisz, jaka jest pierwsza wiadomość, którą otrzymuję, gdy próbuję uruchomić „rpm --install”? błąd: nieudane zależności: ooobasis3.3-sdk-3.3.0-9567.x86_64 potrzebuje ooobasis3.3-core01 - OH JOY!
Falcon
2
@tdammers: masz rację, ale w przypadku, gdybym chciał mieć taką nadmiarowość, gdyby tylko konfiguracja i instalacja była łatwa. A jeśli chcesz zobaczyć piekło zależności, zajrzyj do katalogu / usr / lib. Jest wszystko: redundancja, przewroty, a ty nawet nie wiesz, który program używa której biblioteki. Jasne, pozwól menedżerowi pakietów sobie z tym poradzić! Ale co jeśli kierownik pakietu nie poradzi sobie z tym tak, jak w przypadku otwartego biura, o którym wspominałem. Zasadniczo oznacza to, że jesteś wkręcony i będziesz miał trudności z zainstalowaniem czegoś.
Falcon
2
@tdammers: A im więcej o tym myślę i moje doświadczenia: nie mogę nawet policzyć razy, kiedy musiałem utworzyć dowiązania symboliczne w tym katalogu tylko dlatego, że zależności zawiodły lub jakiś program odmówił uruchomienia, nawet jeśli został zainstalowany za pomocą menedżera pakietów. Być może sytuacja się poprawiła, ale często ciężko jest popracować nad pewnymi sprawami. Problemy, których można by uniknąć, gdyby właśnie przesłali zależność od aplikacji. Z przyjemnością zapłacę kilka MB dodatkowego miejsca, aby uniknąć tego problemu.
Falcon
2
@tdammers: Niezliczone samouczki w Internecie na temat instalowania określonego programu w określonym systemie Linux są świadkami tego problemu.
Falcon
3

To może, ale nie musi dotyczyć twojego przypadku użycia, ale tym, co robimy w pracy, jest folder „Referencje” w każdym oddziale. Umieszczamy tutaj biblioteki DLL stron trzecich. Powoduje to wiele duplikacji względnie niezmiennych plików binarnych w kontroli źródła, ale pamięć jest tania iw każdym momencie każda gałąź i tag ma dokładnie takie zależności (i wersja!), Jakich się spodziewa.

Sami wstępnie kompilujemy zależności i przenosimy skompilowane pliki binarne do tego folderu. Nasza własna wewnętrzna biblioteka współdzielona jest również traktowana w ten sposób. W ten sposób ta sama technika działa w przypadku wstępnie skompilowanych bibliotek zastrzeżonych, bibliotek typu open source i bibliotek wewnętrznych.

Jeśli chodzi o odpowiedź na pytanie teraz, gdy go ponownie przeczytałem, zrób to samo i po prostu wspomnij, że twój projekt używa wstępnie skompilowanej wersji Lua 1.3.5.

Bryan Boettcher
źródło
1

Czy zależność powinna być zawarta w repozytorium?

Można się do niego odwoływać w repozytorium (dowolną użyteczną metodą SCM), jeśli ta zależność stanowi integralną część produktu (zależność od źródła), a nie zależność binarna, którą można rozwiązać osobno

Czy zależność powinna być budowana z tego samego skryptu kompilacji, co z pozostałej części projektu, czy z oddzielnego skryptu kompilacji?

To w ogóle nie ma znaczenia. Możesz wybrać dowolną metodę, zgodnie ze swoimi wymaganiami (prędkość / przezroczystość / łatwość zarządzania / itp.)

Leniwy Borsuk
źródło
0

Będąc sklepem Eclipse, właśnie zaczęliśmy używać Buckminster do zarządzania naszym procesem kompilacji / montażu / wdrażania.

Naszym pierwszym etapem było usunięcie wszystkich istniejących bibliotek zależnych i pozwolenie Buckminsterowi zająć się zmaterializowaniem poprawnych bibliotek. To sprawia, że ​​wdrożenie jest znacznie szybsze i mniejsze.

Następnym krokiem będzie przeniesienie naszego monolitycznego svnrepozytorium do szeregu modułowych gitrepozytoriów.

Nie wiem, jak dobrze buckminster zintegrowałby się z gitsubmodułami (lub podreparatami rtęciowymi w tym przypadku), ale fajnie jest, że buckminster jest agnostyczny w odniesieniu do VCS zastosowanego dla danego komponentu.

Mark Booth
źródło