How Many Package Managers Should I Support?
Monday, 5 May 2014
One of those (from Fabio Fabbrucci, who’s contributed a fair amount) was to add a Package.json file, to make it easier to install with NPM, which seemed fair enough; NPM is a JS package manager, and even though it’s mostly for server-side libraries, hinclude could be useful there.
After a while, I added a bower.json file, since I use Bower. Again, Bower is for managing Web assets, mostly JS, and this fit the bill.
Then I got a pull request to add a composer.json file. Apparently, Composer is a “dependency manager for PHP.” I decided to draw a line in the sand, as it were.
Why Not Composer?
I imagine most engineers would add the file and move on. Why don’t I?
Secondly, if every project always adds these files, there’s no pressure for consolidation. I want to see the Composer people working with the Bower folks, and whoever else, to come up with a single package format, rather than forcing us to duplicate information so many times - DRY is important, even in packaging.
Pragmatically, I should probably just add the file and move on, but I can’t bring myself to do that. Left to their own devices, I suspect these frameworks will get so diverse and complex that we’ll eventually need a “package manager manager” that creates a set of files based on one meta-configuration file, and we’ll have one more component necessary in our toolchains. And that’s kind of crap.
What do you think? Am I being needlessly obstructionist here?