storia
Archivio software
Un repository di software , colloquialmente noto come "repository" in breve, è una posizione di archiviazione da cui i pacchetti software possono essere recuperati e installati su un computer. Questi repository spesso ospitano metadati sui pacchetti memorizzati nel repository. Spesso è possibile installare o aggiornare software locale utilizzando un determinato gestore di pacchetti installato sul computer locale accedendo ai pacchetti archiviati nel repository tramite esso.
Panoramica
Molti editori di software e altre organizzazioni mantengono server su Internet per questo scopo, gratuitamente o con un canone di abbonamento. I repository possono essere esclusivamente per programmi particolari, come CPAN per il linguaggio di programmazione Perl o per un intero sistema operativo. Gli operatori di tali repository in genere forniscono un sistema di gestione dei pacchetti, strumenti destinati a cercare, installare e altrimenti manipolare i pacchetti software dai repository. Ad esempio, molte distribuzioni Linux usano Advanced Packaging Tool (APT), che si trova comunemente nelle distribuzioni basate su Debian o che si trova nelle distribuzioni basate su Red Hat. Esistono anche più sistemi indipendenti di gestione dei pacchetti, come pacman, utilizzati in Arch Linux ed equo, presenti in Sabayon Linux.
Poiché i repository software sono progettati per includere pacchetti utili, i repository principali sono progettati per essere privi di malware. Se un computer è configurato per utilizzare un repository con firma digitale da un fornitore affidabile ed è abbinato a un sistema di autorizzazioni appropriato, ciò riduce significativamente la minaccia di malware per questi sistemi. Come effetto collaterale, molti sistemi che dispongono di queste funzionalità non richiedono software anti-malware come software anti-virus.
La maggior parte delle principali distribuzioni Linux ha molti repository in tutto il mondo che rispecchiano il repository principale.
Sistema di gestione dei pacchetti vs. processo di sviluppo dei pacchetti
Un sistema di gestione dei pacchetti è diverso da un processo di sviluppo dei pacchetti.
Un uso tipico di un sistema di gestione dei pacchetti è quello di facilitare l'integrazione del codice da fonti eventualmente diverse in un'unità operativa autonoma coerente. Pertanto, un sistema di gestione dei pacchetti potrebbe essere utilizzato per produrre una distribuzione di Linux, possibilmente una distribuzione su misura per una specifica applicazione limitata.
Un processo di sviluppo di pacchetti, al contrario, viene utilizzato per gestire il co-sviluppo di codice e documentazione di una raccolta di funzioni o routine con un tema comune, producendo così un pacchetto di funzioni software che in genere non saranno complete e utilizzabili da sole. Un buon processo di sviluppo del pacchetto aiuterà gli utenti a conformarsi alle buone pratiche di documentazione e codifica, integrando un certo livello di test unitari. La tabella seguente fornisce esempi di processi di sviluppo di pacchetti.
Repository selezionati
La tabella seguente elenca alcune lingue con repository per software fornito. La colonna "Autochecks" descrive i controlli di routine effettuati.
Pochissime persone hanno la possibilità di testare il proprio software su più sistemi operativi con diverse versioni del codice principale e con altri pacchetti forniti che possono utilizzare. Per R, la rete completa di archivi R (CRAN) esegue regolarmente test. Per vedere quanto sia prezioso, supponiamo che Sally fornisca un pacchetto A. Sally esegue solo la versione corrente del software con una versione di Microsoft Windows e l'ha testata solo in quell'ambiente. A intervalli più o meno regolari, CRAN verifica il contributo di Sally in una dozzina di combinazioni di sistemi operativi e versioni del software di linguaggio R di base. Se uno di loro genera un errore, riceve quel messaggio di errore. Per fortuna, quel messaggio di errore potrebbe essere sufficiente per consentirle di correggere l'errore, anche se non è in grado di replicarlo con l'hardware e il software in suo possesso. Supponiamo quindi che John contribuisca al repository un pacchetto B che utilizza un pacchetto A. Il pacchetto B supera tutti i test e viene reso disponibile agli utenti. Più tardi, Sally presenta una versione migliorata di A, che purtroppo interrompe B. Gli auto-controlli consentono di fornire informazioni a John in modo che possa risolvere il problema.
Questo esempio mostra sia un punto di forza che un punto debole nel sistema di pacchetti contribuiti R: CRAN supporta questo tipo di test automatizzati dei pacchetti forniti, ma i pacchetti forniti a CRAN non devono specificare le versioni di altri pacchetti forniti che utilizzano. Esistono procedure per richiedere versioni specifiche di pacchetti, ma i contributori potrebbero non utilizzare tali procedure.
Oltre a ciò, un repository come CRAN che esegue controlli regolari dei pacchetti forniti in realtà fornisce una suite di test estesa se ad hoc per le versioni di sviluppo del linguaggio principale. Se Sally (nell'esempio sopra) riceve un messaggio di errore che non capisce o ritiene inappropriato, specialmente da una versione di sviluppo della lingua, può (e spesso fa con R) chiedere aiuto al team di sviluppo principale per la lingua . In questo modo, il repository può contribuire a migliorare la qualità del software del linguaggio principale.
| Lingua / scopo | Processo di sviluppo del pacchetto | deposito | Installa i metodi | Piattaforma di sviluppo collaborativo | Autochecks |
|---|---|---|---|---|---|
| Haskell | Architettura comune per la creazione di applicazioni e librerie | Hackage | |||
| Giava | Maven | ||||
| Julia | |||||
| Lisp comune | Quicklisp | ||||
| .NETTO | NuGet | NuGet | |||
| Node.js | NPM | ||||
| Perl | CPAN | PPM | |||
| PHP | PEAR, compositore | PECL, Packagist | |||
| Pitone | setuptools | PyPI | pip, EasyInstall, PyPM, Anaconda | ||
| R | R Processo di controllo CMD | CRAN | install.packages | R-Forge | Circa settimanalmente su 12 piattaforme o combinazioni di diverse versioni di R (sviluppo, prerel, patch, rilascio) con un massimo di 7 diversi sistemi operativi (diverse versioni di Linux, Windows e Mac). |
| Rubino | RubyGems | Ruby Application Archive | RubyForge | ||
| Ruggine | Carico | casse | Carico | ||
| TeX, LaTeX | CTAN |
(Parti di questa tabella sono state copiate da un "Elenco dei principali repository per linguaggio di programmazione" su Stack Overflow)
Molti altri linguaggi di programmazione, tra cui C, C ++ e Fortran, non possiedono un repository software centrale con ambito universale. Notevoli repository con ambito limitato includono:
- Netlib, principalmente routine matematiche per Fortran e C, storicamente uno dei primi repository software aperti;
- Boost, una raccolta rigorosamente curata di librerie di alta qualità per C ++; parte del codice sviluppato in Boost divenne in seguito parte della libreria standard C ++.
Gestori del repository
Il software per la gestione dei repository (gestori dei repository) include:
- Apache Archiva - "repository di artefatti compilato da software di gestione repository"
- ProGet di Inedo: "Universal Package Manager. Funzionalità di livello mondiale. Accessibile a tutti."
- JFrog's Artifactory - "gestione dei binari durante il ciclo di sviluppo"
- MyGet - "servizio di consegna continua che ospita migliaia di repository di pacchetti NuGet, Bower e NPM"
- Packagecloud - "Un'interfaccia unificata per gli sviluppatori per tutti i tuoi artefatti."
- Package Drone - "un repository gestore pacchetti per OSGi"
- Sonatype's Nexus -: funziona con strumenti di costruzione come Ant, Ivy, Gradle, Maven, SBT tra gli altri.
- Pulp - "piattaforma gratuita e open source per la gestione di repository di pacchetti software e per renderlo disponibile a un gran numero di consumatori. Tipi supportati: RPM, Python, Puppet, Docker e OSTree."
