Is the problem that there’s too much mud being thrown against the wall? Before the explosive popularity of rails, and now node, I don’t recall having these problems.
Back in ye olde times, you’d want to build your program. You’d go to sourceforge and download a couple tarballs as needed and generally not care too much about the version. It mostly seemed to work. Accurate memory or nostalgic revisionism?
All of this dependency tracking and continuous integration and rapid release cycle looks like a giant exercise in make work. If we build tools that let us ship as much broken crap as fast as possible, then we can build even more tools to slow the influx of the crap.
I notice there’s a distinct lack of such articles dedicated to python. Is that just perception? I usually just install whatever, and again, it generally works. Do python devs not care, or have they found some other solution? A more considered release process?
I can’t speak too much about other languages, but part of the problem here is a deficiency in npm. Unlike Bundler for Ruby, npm does not automatically generate a lock/shrinkwrap file. Combine this with npm’s default version ranges in package.json and two people working on exactly the same app can have wildly different dependency trees installed, depending on exactly when they ran npm install.
I’d much prefer it if npm generated the shrinkwrap automatically, and required you to explicitly run npm update to alter the locked-down dependency tree in accordance with the version ranges in package.json.
For what it’s worth, in my C projects I usually just have my /lib or /vendor folder and lug around whatever I need to link with, sometimes only static libs. ¯_(ツ)_/¯
Then again, I take a little more care in picking my dependencies than I do in node land (because the dependency situation in node is just out of control at this point).
Do python devs not care, or have they found some other solution? A more considered release process?
I don’t have any great theory here, besides my own experience, but this seems to match up.
Python libraries offer more stable API’s?
Python programmers are more experienced, and more wary of dependencies? Many Javascript developers are very new to Javascript. The JS devs I work with don’t hesitate to reach for a dependency, even for something like finding the first element in a list.
JS devs will make modules out of anything, for example, here’s a module that’s just an OR statement. More modules = more opportunities for inter-dependency failure, or library breaks.
There are over 100 packages that match the name “bcrypt”.
I wrote a thing about this last week, I avoid this by trying as hard as possible to avoid taking dependencies, and if I do have to take a dependency, to avoid updating it.
Python has a packaging system and it works well with the OS. Javascript has some loose standards that aren’t all adopted by everyone and are largely limited to fighting against the nature of javascript in general. I still wouldn’t call Python’s packaging system a solved problem, just not one that often gets in the way. Nothing in Javascript makes any sense to a systems person (in fact, NPM is very apparently written by folks who may not have a good grasp of integrating into a system. I installed NPM not so many months ago and it overwrote my /bin/which binary, which wasn’t a problem until I needed to update and it deleted its replacement).
It’s getting better, but there is no consensus or even finite terminology. What a “package” is depends on context and who wants it to be what. What a package manager is also changes (for instance bower is a package manager despite having no concept of dependencies, which I would instead call a downloader at best). I don’t know what the future holds for our javascript community, but I know that for me, I hate working within it outside of anything but toy programs.
bower is a package manager despite having no concept of dependencies
That’s not quite accurate. Bower does understand dependencies. If you try to install angular-route, it will automatically install angular, for example. However, Bower doesn’t understand module formats, module loading, or bundling. You have to supply those parts yourself, possibly with something like grunt-bower-concat.
Is the problem that there’s too much mud being thrown against the wall? Before the explosive popularity of rails, and now node, I don’t recall having these problems.
Back in ye olde times, you’d want to build your program. You’d go to sourceforge and download a couple tarballs as needed and generally not care too much about the version. It mostly seemed to work. Accurate memory or nostalgic revisionism?
All of this dependency tracking and continuous integration and rapid release cycle looks like a giant exercise in make work. If we build tools that let us ship as much broken crap as fast as possible, then we can build even more tools to slow the influx of the crap.
I notice there’s a distinct lack of such articles dedicated to python. Is that just perception? I usually just install whatever, and again, it generally works. Do python devs not care, or have they found some other solution? A more considered release process?
I can’t speak too much about other languages, but part of the problem here is a deficiency in npm. Unlike Bundler for Ruby, npm does not automatically generate a lock/shrinkwrap file. Combine this with npm’s default version ranges in
package.jsonand two people working on exactly the same app can have wildly different dependency trees installed, depending on exactly when they rannpm install.I’d much prefer it if npm generated the shrinkwrap automatically, and required you to explicitly run
npm updateto alter the locked-down dependency tree in accordance with the version ranges inpackage.json.For what it’s worth, in my C projects I usually just have my
/libor/vendorfolder and lug around whatever I need to link with, sometimes only static libs. ¯_(ツ)_/¯Then again, I take a little more care in picking my dependencies than I do in node land (because the dependency situation in node is just out of control at this point).
I don’t have any great theory here, besides my own experience, but this seems to match up.
I wrote a thing about this last week, I avoid this by trying as hard as possible to avoid taking dependencies, and if I do have to take a dependency, to avoid updating it.
Python has a packaging system and it works well with the OS. Javascript has some loose standards that aren’t all adopted by everyone and are largely limited to fighting against the nature of javascript in general. I still wouldn’t call Python’s packaging system a solved problem, just not one that often gets in the way. Nothing in Javascript makes any sense to a systems person (in fact, NPM is very apparently written by folks who may not have a good grasp of integrating into a system. I installed NPM not so many months ago and it overwrote my /bin/which binary, which wasn’t a problem until I needed to update and it deleted its replacement).
It’s getting better, but there is no consensus or even finite terminology. What a “package” is depends on context and who wants it to be what. What a package manager is also changes (for instance bower is a package manager despite having no concept of dependencies, which I would instead call a downloader at best). I don’t know what the future holds for our javascript community, but I know that for me, I hate working within it outside of anything but toy programs.
Again, though, it’s getting better.
That’s not quite accurate. Bower does understand dependencies. If you try to install angular-route, it will automatically install angular, for example. However, Bower doesn’t understand module formats, module loading, or bundling. You have to supply those parts yourself, possibly with something like grunt-bower-concat.
This is good advice. I’ve found that using version ranges for libraries and shrinkwrapped dependencies for apps works out well.