Difference between revisions of "Dependency managers"
m (added Category:DevOps using HotCat) |
m (added Category:DevOps using HotCat) |
(No difference)
|
Latest revision as of 10:55, 30 June 2016
Ever since the RPM format was invented (and surely even before), there have been epic fights against dependency hell. The Debian packaging format was a blessing for me, and I quickly fell in love with apt-get long ago. Since then, there have been many more projects which have grown into large ecosystems of software, and managing versions as well as dependencies has always been an issue in DevOps. Here then is a space dedicated to some of those solutions.
Packaging[edit | edit source]
Packaging software is different, albeit related, to managing dependencies. For example, the PHAR format is a way to package PHP software. In the old days files were simply compressed and packaged using GZip and Tar.
PHP[edit | edit source]
In the old days (starting in 1999), there was PEAR Now there is Composer, which is based on Node's npm and Ruby's bundler
MediaWiki[edit | edit source]
http://wiki.4intra.net/Repo.php is a hybrid approach similar to git submodules that probably could be interesting.
JavaScript[edit | edit source]
Node has npm. https://www.npmjs.org/
Version Control[edit | edit source]
In addition to managing dependencies during the installation of software, you also want to manage dependencies during the development of software. And your version control system should support that. Subversion has a notion of 'externals' which can be rather cumbersome and is not really much more than a symlink manager. Git offers 'submodules' [1]. Submodules can work great, but it's important to understand how to use them so that you don't wind up creating more problems than you solve. The point is to have a VCS system that allows you to bundle third-party software and libraries into your source code repository.