Difference between revisions of "Dependency managers"
m (added Category:DevOps using HotCat) |
(Created page with "Ever since the RPM format was invented (and surely even before), there have been epic fights against wp:dependency hell. The Debian packaging format was a blessing for me...") |
||
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | Ever since the RPM format was invented (and surely even before), there have been epic fights against [[wp: | + | Ever since the RPM format was invented (and surely even before), there have been epic fights against [[wp: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 == | == Packaging == | ||
| − | Packaging software is different, albeit related, to managing dependencies. For example, the < | + | Packaging software is different, albeit related, to managing dependencies. For example, the <abbrev title="PHP Archive>PHAR</abbrev> format is a way to package PHP software. In the old days files were simply compressed and packaged using [[GZip]] and [[Tar]]. |
== PHP == | == PHP == | ||
| − | In the old days (starting in 1999), there was [http://pear.php.net/ PEAR] Now there is [https://getcomposer.org/ Composer], which is based on Node's npm and Ruby's [http://bundler.io/ bundler] | + | In the old days (starting in 1999), there was [http://pear.php.net/ PEAR] Now there is [https://getcomposer.org/ Composer], which is based on Node's npm and Ruby's [[http://bundler.io/ bundler]] |
== MediaWiki == | == MediaWiki == | ||
| Line 11: | Line 11: | ||
== JavaScript == | == JavaScript == | ||
| − | Node has npm. https://www.npmjs.org/ | + | Node has <abbrev title="Node Packaged Modules">npm</abbrev>. https://www.npmjs.org/ |
== Version Control == | == Version Control == | ||
| Line 19: | Line 19: | ||
[[Category:Development]] | [[Category:Development]] | ||
| − | |||
| − | |||
Revision as of 13:35, 11 November 2014
Ever since the RPM format was invented (and surely even before), there have been epic fights against wp: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 <abbrev title="PHP Archive>PHAR</abbrev> 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 <abbrev title="Node Packaged Modules">npm</abbrev>. 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.
