1. 29

    In the Hacker News thread about the new Go package manager people were angry about go, since the npm package manager was obviously superior. I can see the quality of that now.

    There’s another Lobster thread right now about how distributions like Debian are obsolete. The idea being that people use stuff like npm now, instead of apt, because apt can’t keep up with modern software development.

    Kubernetes official installer is some curl | sudo bash thing instead of providing any kind of package.

    In the meantime I will keep using only FreeBSD/OpenBSD/RHEL packages and avoid all these nightmares. Sometimes the old ways are the right ways.

    1. 7

      “In the Hacker News thread about the new Go package manager people were angry about go, since the npm package manager was obviously superior. I can see the quality of that now.”

      I think this misses the point. The relevant claim was that npm has a good general approach to packaging, not that npm is perfectly written. You can be solving the right problem, but writing terribly buggy code, and you can write bulletproof code that solves the wrong problem.

      1.  

        npm has a good general approach to packaging

        The thing is, their general approach isn’t good.

        They only relatively recently decided locking down versions is the Correct Thing to Do. They then screwed this up more than once.

        They only relatively recently decided that having a flattened module structure was a good idea (because presumably they never tested in production settings on Windows!).

        They decided that letting people do weird things with their package registry is the Correct Thing to Do.

        They took on VC funding without actually having a clear business plan (which is probably going to end in tears later, for the whole node community).

        On and on and on…

        1.  

          Go and the soon-to-be-official dep dependency managment tool manages dependencies just fine.

          The Go language has several compilers available. Traditional Linux distro packages together with gcc-go is also an acceptable solution.

          1.  

            It seems the soon-to-be-official dep tool is going to be replaced by another approach (currently named vgo).

          2. 1

            I believe there’s a high correlation between the quality of the software and the quality of the solution. Others might disagree, but that’s been pretty accurate in my experience. I can’t say why, but I suspect it has to do with the same level of care put into both the implementation and in understanding the problem in the first place. I cannot prove any of this, this is just my heuristic.

            1. 8

              You’re not even responding to their argument.

              1.  

                There’s npm registry/ecosystem and then there’s the npm cli tool. The npm registry/ecosystem can be used with other clients than the npm cli client and when discussing npm in general people usually refer to the ecosystem rather than the specific implementation of the npm cli client.

                I think npm is good but I’m also skeptical about the npm cli tool. One doesn’t exclude the other. Good thing there’s yarn.

                1.  

                  I think you’re probably right that there is a correlation. But it would have to be an extremely strong correlation to justify what you’re saying.

                  In addition, NPM isn’t the only package manager built on similar principles. Cargo takes heavy inspiration from NPM, and I haven’t heard about it having a history of show-stopping bugs. Perhaps I’ve missed the news.

              2. 8

                The thing to keep in mind is that all of these were (hopefully) done with best intentions. Pretty much all of these had a specific use case… there’s outrage, sure… but they all seem to have a reason for their trade offs.

                • People are angry about a proposed go package manager because it throws out a ton of the work that’s been done by the community over the past year… even though it’s fairly well thought out and aims to solve a lot of problems. It’s no secret that package management in go is lacking at best.
                • Distributions like Debian are outdated, at least for software dev, but their advantage is that they generally provide a rock solid base to build off of. I don’t want to have to use a version of a python library from years ago because it’s the only version provided by the operating system.
                • While I don’t trust curl | sh it is convenient… and it’s hard to argue that point. Providing packages should be better, but then you have to deal with bug reports where people didn’t install the package repositories correctly… and differences in builds between distros… and… and…

                It’s easy to look at the entire ecosystem and say “everything is terrible” but when you sit back, we’re still at a pretty good place… there are plenty of good, solid options for development and we’re moving (however slowly) towards safer, more efficient build/dev environments.

                But maybe I’m just telling myself all this so I don’t go crazy… jury’s still out on that.

                1.  

                  Distributions like Debian are outdated, at least for software dev,

                  That is the sentiment that seems to drive the programming language specific package managers. I think what is driving this is that software often has way too many unnecessary dependencies causing setup of the environment to build the software being hard or taking lots of time.

                  I don’t want to have to use a version of a python library from years ago because it’s the only version provided by the operating system.

                  Often it is possible to install libraries at another location and redirect your software to use that though.

                  It’s easy to look at the entire ecosystem and say “everything is terrible” but when you sit back, we’re still at a pretty good place…

                  I’m not so sure. I forsee an environment where actually building software is a lost art. Where people directly edit interpreted files in place inside a virtual machine image/flatpak/whatever because they no longer know how to build the software and setup the environment it needs. And then some language specific package manager for distributing these images.

                  I’m growing more disillusioned the more I read Hacker News and lobste.rs… Help me be happy. :)

                  1.  

                    So like squeak/smalltalk images then? Whats old is new again I suppose.

                    http://squeak.org

                    1.  

                      I’m not so sure. I forsee an environment where actually building software is a lost art. Where people directly edit interpreted files in place inside a virtual machine image/flatpak/whatever because they no longer know how to build the software and setup the environment it needs. And then some language specific package manager for distributing these images.

                      You could say the same thing about Docker. I think package managers and tools like Docker are a net win for the community. They make it faster for experienced practitioners to setup environments and they make it easier for inexperienced ones as well. Sure, there is a lot you’ve gotta learn to use either responsibly. But I remember having to build redis every time I needed it because it wasn’t in ubuntu’s official package manager when I started using it. And while I certainly appreciate that experience, I love that I can just install it with apt now.

                    2.  

                      I don’t want to have to use a version of a python library from years ago because it’s the only version provided by the operating system.

                      Speaking of Python specifically, it’s not a big problem there because everyone is expected to work within virtual environments and nobody runs pip install with sudo. And when libraries require building something binary, people do rely on system-provided stable toolchains (compilers and -dev packages for C libraries). And it all kinda works :-)

                      1.  

                        I think virtual environments are a best practice that unfortunately isn’t followed everywhere. You definitely shoudn’t run pip install with sudo but I know of a number of companies where part of their deployment is to build a VM image and sudo pip install the dependencies. However it’s the same thing with npm. In theory you should just run as a normal user and have everything installed to node_modules but this clearly isn’t the case, as shown by this issue.

                        1. 5

                          nobody runs pip install with sudo

                          I’m pretty sure there are quite a few devs doing just that.

                          1.  

                            Sure, I didn’t count :-) The important point is they have a viable option not to.

                          2.  

                            npm works locally by default, without even doing anything to make a virtual environment. Bundler, Cargo, Stack etc. are similar.

                            People just do sudo because Reasons™ :(

                        2.  

                          It’s worth noting that many of the “curl | bash” installers actually add a package repository and then install the software package. They contain some glue code like automatic OS/distribution detection.

                          1.  

                            I’d never known true pain in software development until I tried to make my own .debs and .rpms. Consider that some of these newer packaging systems might have been built because Linux packaging is an ongoing tirefire.

                            1.  

                              with fpm https://github.com/jordansissel/fpm it’s not that hard. But yes, using the Debian or Redhat blessed was to package stuff and getting them into the official repos is def. painful.

                              1.  

                                I used the gradle plugins with success in the past, but yeah, writing spec files by hand is something else. I am surprised nobody has invented a more user friendly DSL for that yet.

                                1.  

                                  A lot of difficulties when doing Debian packages come from policy. For your own packages (not targeted to be uploaded in Debian), it’s far easier to build packages if you don’t follow the rules. I like to pretend this is as easy as with fpm, but you get some bonus from it (building in a clean chroot, automatic dependencies, service management like the other packages). I describe this in more details here: https://vincent.bernat.im/en/blog/2016-pragmatic-debian-packaging

                                2.  

                                  It sucks that you come away from this thinking that all of these alternatives don’t provide benefits.

                                  I know there’s a huge part of the community that just wants things to work. You don’t write npm for fun, you end up writing stuff like it because you can’t get current tools to work with your workflow.

                                  I totally agree that there’s a lot of messiness in this newer stuff that people in older structures handle well. So…. we can knowledge share and actually make tools on both ends of the spectrum better! Nothing about Kubernetes requires a curl’d installer, after all.

                                1. 2

                                  Does his gopher link still work? The gopher client has been removed from most browsers.

                                  1. 3

                                    This random gopher proxy seems to render his page just fine.

                                    Apparently there was an add-on/plugin called Overbite that used to make Firefox/Chrome natively support the gopher protocol, but it seems like last round of add-on API changes broke it permanently.