The situation with packages and dependency hell today is horrendous, particularly if you work in a highly dynamic environment like web development.<p>I want to illustrate this with a detailed example of something I did just the other day, when I set up the structure for a new single page web application. Bear with me, this is leading up to the point at the end of this post.<p>To build the front-end, I wanted to use these four tools:<p>- jQuery (a JavaScript library)<p>- Knockout (another JavaScript library)<p>- SASS (a preprocessor to generate CSS)<p>- Jasmine (a JavaScript library/test framework)<p>Notice that each of these directly affects how I write my code. You can install any of them quite happily on its own, with no dependencies on any other tool or library. They are all actively maintained, but if what you’ve got works and does what you need then generally there is no need to update them to newer versions all the time either. In short, they are excellent tools: they do a useful job so I don’t have to reinvent the wheel, and they are stable and dependable.<p>In contrast, I’m pretty cynical about a lot of the bloated tools and frameworks and dependencies in today’s web development industry, but after watching a video[1] by Steven Sanderson (the creator of Knockout) where he set up all kinds of goodies for a large single page application in just a few minutes, I wondered if I was getting left behind and thought I’d force myself to do things the trendy way.<p>About <i>five hours</i> later, I had installed or reinstalled:<p>- 2 programming languages (Node and Ruby)<p>- 3 package managers (npm with Node, gem with Ruby, and Bower)<p>- 1 scaffolding tool (Yeoman) and various “generator” packages<p>- 2 tools that exist only to run other software (Gulp to run the development tasks, Karma to run the test suite) and numerous additional packages for each of these so they know how to interact with everything else<p>- 3 <i>different</i> copies of the same library (RequireJS) within my single project’s source tree, one installed via npm and two more via Bower, just to use something resembling modular design in JavaScript.<p>And this lot in turn made some undeclared assumptions about other things that would be installed on my system, such as an entire Microsoft Visual C++ compiler set-up. (Did I mention I’m running on Windows?)<p>I discovered a number of complete failures along the way. Perhaps the worst was what caused me to completely uninstall my existing copy of Node and npm — which I’d only installed about three months earlier — because the scaffolding tool <i>whose only purpose is to automate the hassle of installing lots of packages and templates</i> completely failed to install numerous packages and templates using my previous version of Node and npm, and npm itself <i>whose only purpose is to install and update software</i> couldn’t update <i>Node and npm themselves</i> on a Windows system.<p>Then I uninstalled and reinstalled Node/npm again, because it turns out that using 64-bit software on a 64-bit Windows system is silly, and using 32-bit Node/npm is much more widely compatible when its packages start borrowing your Visual C++ compiler to rebuild some dependencies for you. Once you’ve found the correct environment variable to set so it knows which version of VC++ you’ve actually got, that is.<p>I have absolutely no idea how this constitutes progress. It’s clear that many of these modern tools are only effective/efficient/useful at all on Linux platforms. It’s <i>not</i> clear that they would save significant time even then, compared to just downloading the latest release of the tools I actually wanted (there were only four of those, remember, or five if you count one instance of RequireJS).<p>And here’s the big irony of the whole situation. The <i>only</i> useful things these tools actually did, when all was said and done, were:<p>- Install a given package within the local directory tree for my project, with certain version constraints.<p>- Recursively install any dependent packages the same way.<p>That’s it. There is no more.<p>The only things we need to solve the current mess are standardised, cross-platform ways to:<p>- find authoritative package repostories and determine which packages they offer<p>- determine which platforms/operating systems are supported by each package<p>- determine the available version(s) of each package on each platform, which versions are compatible for client code, and what the breaking changes are between any given pair of versions<p>- indicate the package/version dependencies for a given package on each platform it supports<p>- install and update packages, either locally in a particular “virtual world” or (optionally!) globally to provide a default for the whole host system.<p>This requires each platform/operating system to support the concept of the virtual world, each platform/operating system to have a single package management tool for installing/updating/uninstalling, and each package’s project and each package repository to provide information about versions, compatibility and dependencies in a standard format.<p>As far as I can see, exactly none of this is harder than problems we are already solving numerous different ways. The only difference is that in my ideal world, the people who make the operating systems consider lightweight virtualisation to be a standard feature and provide a corresponding universal package manager as a standard part of the OS user interface, and everyone talks to each other and consolidates/standardises instead of always pushing to be first to reinvent another spoke in one of the wheels.<p>We built the Internet, the greatest communication and education tool in the history of the human race. Surely we can solve package management.<p>[1] <a href="http://blog.stevensanderson.com/2014/06/11/architecting-large-single-page-applications-with-knockout-js/" rel="nofollow">http://blog.stevensanderson.com/2014/06/11/architecting-larg...</a>