Studie s příhodným názvem DéjàVu se zaměřila na duplicitní kód na GitHubu. Projekt prozkoumal 4,5 miliónů neforkovaných projektů, což odpovídá asi 428 miliónům souborů v Javě, Pythonu, C++ a JS. Tento soubor měl jen 85 miliónů unikátních souborů, tedy 70 % souborů jsou kopie již dříve vytvořených souborů.
Nejvíce duplicit měl JS, kde jen 6 % souborů bylo unikátních. Nejméně pak Java, kde bylo unikátních souborů 60 %. Více v článku, surová data jsou též dostupná.
(zdroj: slashdot)
Jediny nefusersky pristup v pripade pouzivania 3rd party komponentov je nechat 3rd party komponenty 3rd party komponentami a nesahat do nich. Ak sa do nich saha, tak to maju byt zmeny, ktore opravuju alebo rozsiruju funkcionalitu 3rd party komponentu ako takeho *a tieto potom pretlacit do upstreamu*. Zdrojovy kod 3rd party komponentu nie je miesto na aplikovanie vendor-specific hackov. Tie treba drzat mimo komponentu (nad jeho verejnym API).
Cokolvek menej striktne ako takyto pristup je cisto cista a nefalsovana fuserina a skor ci neskor sa vypomsti. Intenzita pomsty a naklady na splatenie "tech debtu" potom rastu s invazivnostou, lajdackostou prevedenia zmeny, vseobecnej exponovanosti 3rd party komponentu, jeho komplexitou a dolezitostou dalsej existencie kodu, ktory tak ucinil. Nie je ale otazkou toho, ci. Spravna otazka je: kedy.
A little copying is better than a little dependency. (Go proverb)
Závislosti v js (node.js) jsou docela peklo, zvláště pokud se o vyvíjený produkt nemůžete starat kontinuálně, ale dostanete se k tomu tak 3-4x do roka. To kam došel npm ekosystém hraničí s neudržitelností, i relativně malé projekty mají i tisíce závislostí, kolikrát jeden modul i v několika verzích. Velice často ty moduly mají do 100 řádků a z nějakého neznámého důvodu autoři s oblibou kompletně mění API. Takže když chcete po půl roce aktualizovat verze (třeba i z nějakých bezpečnostních důvodů), donutí vás to významně zasáhnout do aplikace. Proti tomu je práce se standardní knihovnou Go vysvobození, aktualizujete na novou verzi a vše jede jak má. V používaných knihovnách se API mění jen opravdu výjimečně.
Od toho máš právě možnost udělat fork cizí knihovny a přidat si tam vlastní úpravy nebo něco opravit (pokud to původní autor nechce přijmout do hlavní větve nebo už se o projekt nestará). Pak používáš pořád knihovnu (tzn. v tomto výzkumu by se to neobjevilo jako duplicita, protože je to fork) a přitom nejsi závislý na někom jiném.
A pokud bude žádoucí změnu zpropagovat do jiné větve, pomůže ti s tím verzovací systém (merge, cherry-pick).
A pokud bys ten kód místo forku zkopíroval, tak ho udržovat nemusíš?
Kopírování dává smysl v případě, že bys z velké knihovny potřeboval malý kousek kódu. Ale i v takovém případě by šlo hledat čistější řešení – např. usilovat o rozdělení knihovny na menší modul (resp. knihovny by se takhle už měly navrhovat) nebo použít jinou knihovnu, která není tak rozsáhlá.
Přesně. Nejen že ho musí udržovat dál, ale navíc ho odpojí od původního kódu, je těžší sledovat změny, dělat backporty oprav, prakticky zabrání tomu aby se jeho úpravy dostaly snadno do upstreamu… Geniální nápad, tohle kopírování celých knihoven…
=======
např. usilovat o rozdělení knihovny na menší modul (resp. knihovny by se takhle už měly navrhovat)
=======
Hodně štěstí ve takovém vyjednávání s autorem knihovny. Zkoušel jsi to někdy? Párkrát jsem se pokoušel přesvědčit autory větších projektů o větší flexibilitu a skončilo to "forkni si to a u sebe si dělej, co potřebuješ". A celkem je i chápu, dělají to především pro vlastní potřebu a moje úpravy by jim konkrétně nijak nepomohly.
Pokud vytvoříte fork jinak než integrovaným "fork" tlačítkem, tak se to nebude ukazovat jako fork. Já takhle dost často změním projekt, přidám repository a pushnu to k sobě na github. Github ale nevidí, že je to fork něčeho.
Mám pocit, že na rootu je čím dál tím více zapšklých a frustrovaných jedinců.
Mluvis mi z duse ... nekteri tu chodi jenom proto, aby se mohli na foru pohadat nad kazdou krarvinou. Ale na rootu bylo vzdy hodne zapsklych a frustrovanych jedincu.
Ten tvuj pristup ale neni dobry, protoze pak opravim chybu v nejake knihovne a pak zjistim, ze uz to opravil nekdo jiny ve svem projektu.
Jak uděláte pull request z repository, o kterém GitHub neví, že je to klon toho originálního repository? Předpokládám, že se bavíme o GitHub pull requestu, ne o zaslání patche e-mailem.
https://github.com/github/hub a něco ve stylu hub pull-request
To má být otázka nebo odpověď? Protože hub je jen aplikace pro příkazovou řádku, která umožňuje ovládat GitHub. Pořád se tam dělá fork a následný pull-request.
no to je právě ono, pokud máš práva na daný repositář, můžeš takhle udělat PR aniž bys musel danou branch mít v tom repositáři, je to PR bez forku, ale jen pro členy.
Na githubu jinak nelze udělat PR do cizího repositáře bez toho, abych měl fork, obhajují to kvůli security a možnostem spamu repositářů.
Já si právě také myslím, že to nejde, proto mne překvapilo tvrzení Kallsymse, že to tak dělá, a ještě se tvářil, že je to úplně běžné.
Ano, s tím, že někdo nechápe psaný text, mám problém často. Překvapivě často mám problém i s tím, že psaný text nechápe sám jeho autor. Psal jsem snad někde, že se fork vždy vytváří za účelem pull requestu? Nepsal. Pouze jsem se ptal na ten případ, kdy někdo vytvoří fork (pomocí klonování, ne pomocí funkce GitHubu) a pak z toho nezávislého forku dělá pull request. Vycházel jsem z vašeho textu:
Ono je to dost často i kvůli tomu, že pokud chce člověk přispět, tak si vytvoří fork, tam udělá změny a pošle pull request.
A když Lazywriter připomněl, že se zkoumaly neforkované projekty, dotčeně a arogantně jste doplnil, že jste samozřejmě nemyslel fork vytvořený pomocí funkce GitHubu ale pouze pomocí klonování repository.
Tak spriemerovane to nedava velky zmysel ale po kratkom studiu sa zistilo ze:
Duplications:
JavaScript - 94%
C++ - 73%
Python - 71%
Java - 40%
V Javascripte je najvacsi problem NPMko a neschopny pouzivatelia ktory adresara _modules pchaju do version systemu. C++ je pochopitelne kedze kazdy si chce vytvarat svoju vlastnu odnoz zakladnych kniznic alebo z nich nieco vyrezat alebo mierne upravit a neexistencia standardizovaneho modularneho systemu (podobneho MAVEN v Jave).
Docela by mě zajímalo, kolik z Pythonu budou obdobně nakopírované VIrtualenvy. :)
to uz musi byt ten clovek nesvojpravny ked pushe do svojho repa aj obshaj venv - resp. moze sa to stat raz, ak zabudnete updatovat .gitignore, ale ak to tam ma niekto standartne, tak zbohom. na taketo veci by mal mozno upozornovat aj samotny github, pre kazdu jazyk sa najdu taketo common issues
Ten JS chapu. Napriklad mam v jednom svem projektu, psanem v Pythonu btw, i minifikovany JQuery pro web cast, takze je to samozrejme duplicita.
Asi by to slo nahradit nejakym README nebo necim podobnym, kde by se psalo, jak si stahnout tu konkretni verzi JQuery (nebo tam hodit skript s curl a resit issues s uzivatelama, kteri ho na systemu nemaji nebo jim to neprojde pres FW a ja nevim co jeste). Uz to tedy nebude tak jednoduche jako ve stylu "potrebujete p 2.7/p >3.4, udelejte git clone, spustte skript run.py a appka pojede". Taky by slo pouzivat JQuery odnekud z webu, ale to je zase dost fragilni, prohlizece to muzou odmitat (poustes JS z cizi stranky) a tak.
Přidávat do projektu závislost na npm a všech jeho závislostech jenom proto, abych si stáhnul jednu JavaScriptovou knihovnu v jednom souboru, to mi připadá dost šílené. npm se používá pro JavaScriptové aplikace, po Python je lepší použít nějaký buildovací nástroj určený pro Python.
Napriklad mam v jednom svem projektu, psanem v Pythonu btw, i minifikovany JQuery pro web cast
