Szybsze instalowanie wielu pakietów pod rząd

Hej. Podejrzewam, że nie tylko ja mam taki problem: Żeby projekt wystartował, to oprócz samego Delphi jeszcze potrzeba masę zewnętrznych komponentów. Co robicie? Wszystko ręcznie? Z tego co mi wiadomo można zbudować *.bpl z konsoli przez dcc32 albo msbuild, to i tak dalej trzeba przynajmniej w części ogarnąć to w IDE, a jeśli pakiety które instalujesz są od siebie zależne, to już chyba szybciej będzie wszystko zrobić z IDE. Jedno o czym jeszcze myślałem, to jeśli wszystkie pakiety zewnętrzne są darmowe, to można sobie skompilować bple, wrzucić na GitHuba czy gdzieś i już następne osoba, która stawia sobie środowisko nie musi przynajmniej przez kompilację wszystkiego przechodzić. Macie jakieś swoje metody żeby ten proces przyspieszyć?

Nie bardzo rozumiem, w czym problem, używałem różnych wersji delphi i nigdy nie miałem problemu z instalacją kontrolek. Jest to łatwe i szybkie.
Co do kompilacji bpl i upload, to ogranicza cie tylko licencja. A jeżeli problem rozbija się o instalacje nowego środowiska (np dla nowego pracownika) to VM albo klonowanie dysku z templatki jeżeli instalacja jest taka uciążliwa.

Współczesnego Delphi nie znam, więc nie będę mędrkował.

Natomiast gdybym czegoś takiego potrzebował w Lazarusie, to bym po prostu stworzył pakiet, w skład którego wchodziłyby wszystkie potrzebne moduły oraz inne pakiety (jako zależności). W ten sposób instalując ten ”zbiorczy” pakiet, instalowałoby się wszystko za jednym razem, zamiast ręcznie instalować każdy z osobna. Żeby to miało ręce i nogi, wszystkie pliki modułów i pakietów wrzuciłbym sobie do jednego katalogu, a pliki zbiorczego pakietu byłyby bezpośrednio w tym katalogu. Taki katalog można łatwo skompresować i przenosić pomiędzy maszynami.

Być może pakiety w Delphi działają w podobny sposób i można w ten sposób ułatwić sobie instalację. Przy czym Delphi wspiera dynamiczną instalację pakietów (bez przebudowywania całego IDE), więc ich instalacja jest wygodniejsza (szybsza).

@flowCRANE ogólnie tak, ale istnieją pakiety które są komercyjne i wymagają "osobnej instalacji" np taki trichview. Jego już tak sobie nie dodasz do zbiorczego pakietu.

Nie do końca kumam problem więc opiszę co zrozumiałem.

1. Masz projekt który przy kompilacji wymaga szeregu komponentów. W takiej formie ja przynajmniej w ide mam zawsze grupę projektową i odpowiedni order w tej grupie powoduje, że najpier kompilują mi się biblioteki, a dopiero potem docelowa aplikacja. To jest banał więc chyba nie o to pytałeś
2. Uruchomienie projektu na innym środowisku (np zatrudnienie nowego developera). W obecnej firmie zrobiliśmy to tak, że nowy dev jak sobie zainstaluje delphi ściąga katalog (z udziału sieciowego) z komponentami na swój dysk lokalny (zalecamy np D:\Delphi\Components) i dajemy mu plik *.reg, który ustawia mu w delphi ścieżki właśnie na komponenty z tego katalogu szybko sprawnie i przyjemnie
3. Kompilacja i dostarczenie do "paczki" / "instalki" wszystkich potrzebnych plików (np bpl, dll itd). Poprzez RTTI możesz sobie napisać kawałek kodu, który wszystkie zależne obiekty ci znajdzie i dorzuci do instalatora. Przykładowo w obecnej firmie mamy proces CI/CD oparty o jenkinsa i właśnie konsolowe dcc32.exe. Po CR i po scaleniu PR ze zmianami do gałęzi test/master leci webhook z gitea (bo tego używamy akurat ale te webhooki są na każdej platformie z git'em czy to bitbucket czy to gitlab czy cokolwiek innego jakiś webhook powinien być) do jenkinsa. Jenkins odpala zadanie gdzie z tego PR wie jakie moduły należy przekompilować, sprawdza dependencies poszczególnych modułów i kompiluje najpierw te biblioteki zależne, a dopiero potem moduły / exe docelowe. W linii komend do dcc32.exe można tez podać ścieżki outputowe więc od razu jenkins wystawia nowe wersje plików/bpl/dll na odpowiedni udział sieciowy dzięki czemu testerzy od razu po otrzymaniu maila z jenkinsa wiedzą, że jest nowa wersja i mogą się zacząć znęcać. W razie jakiegoś błędu jenkins od razu do gitea wrzuca nam linka do logu z danego zadania jako komentarz.

Mam nadzieje, że któryś z punktów jest odpowiedzią na twoje pytanie

Najlepszym i najnowocześniejszym sposobem na zarządzanie zależnościami w Delphi jest użycie menedżera pakietów Boss. Działa on bardzo podobnie do narzędzi znanych z innych technologii, takich jak NPM (w świecie JavaScript) czy NuGet (w .NET).

Instalujesz Boss: To proste narzędzie konsolowe.
Tworzysz plik boss.json: W głównym katalogu swojego projektu tworzysz plik tekstowy, w którym deklarujesz wszystkie potrzebne komponenty, wskazując na ich repozytorium na GitHubie.

Przykład pliku boss.json:

{
  "name": "MyAwesomeProject",
  "description": "An awesome project.",
  "version": "1.0.0",
  "homepage": "https://github.com/user/myawesomeproject",
  "dependencies": {
    "https://github.com/pbe-dvlp/delphi-printers": "^1.0.2",
    "https://github.com/viniciussanchez/dataset-serialize": "^v2.4.5",
    "https://github.com/bittencourtthulio/delphi-mvvm": "master"
  }
}

Uruchamiasz jedno polecenie: W konsoli, w katalogu projektu, wpisujesz:

Bash
boss install

Boss automatycznie:

1. Pobiera kody źródłowe wszystkich komponentów (i ich zależności!) z GitHuba do folderu modules.
2. Kompiluje pakiety (.dpk) dla Twojej wersji Delphi i platformy.
3. Automatycznie dodaje ścieżki do skompilowanych plików (.dcu) i źródeł (.pas) do pliku konfiguracyjnego projektu (.dproj).

Dzięki temu nowy programista w zespole musi jedynie:

1. Sklonować repozytorium projektu.
2. Uruchomić boss install.
3. Otworzyć projekt w Delphi i wszystko jest gotowe do pracy.

Opi napisał(a):

Najlepszym i najnowocześniejszym sposobem na zarządzanie zależnościami w Delphi jest użycie menedżera pakietów Boss. Działa on bardzo podobnie do narzędzi znanych z innych technologii, takich jak NPM (w świecie JavaScript) czy NuGet (w .NET).

Niby fajnie, ale czy naprawdę aż tak często używacie komponentów które muszą być klikalne i zarządzalne w IDE? Zasadniczo moim zdaniem najlepiej jest mieć naprawdę minimalną ilość komponentów typu FastReport (czy inne do tworzenia raportów) i jakiś typu "power grid" (jeśli potrzebujemy), zestaw komponentów bazodanowych, a resztę dołączać w postaci źródeł? Naprawdę nie wszystko musi być komponentem nanoszonym w IDE na formatki. Znacznie to upraszcza zarządzanie projektem i kompilowanie. Jak również pracę w zespole. Bo jak widzę jak niektórzy instalują komponent TComPort i umieszczają go na formatce tylko po to aby nawiązać komunikację po porcie COM to aż mnie krew zalewa.