1. 9
  1. 16

    It is reasonable to expect developers to have more or less a similar environment to yours.

    No, no it is not. A dev might be attached to Yarn instead of NPM. A dev might be on Debian stable instead of Arch or NixOS or Gentoo. A dev might be using an old x86 chip, or some SPARC or MIPS processor. They might only have musl instead of glibc. They might be running a weird variant of Ruby. They might use ASDF instead of however you prefer to manage Elixir or Erlang. They might be blind.

    It’s only reasonable to assume that developers have read your documentation and have followed your instructions re: development environment and dependencies…anything else is just wishful thinking.

    1. 3

      I might edit that to make it less ambiguous in terms of what of what I mean by “expect”, part of which is to read the documentation :)

      1. 1

        No worries! I thought it was a good writeup otherwise. :)

      2. 1

        Pin your version in CI. That’s why CI providers offer features like “build matrix” and “source image”.

        For example, in spite of the recent release of Rust 2018, ammonia (Rust’s go-to HTML sanitization library and a personal project of mine) does not use it. I guarantee this with an advertised minimal version of Rust 1.24 in the README, and running the test suite against 1.24 in CI. The choice was kind of arbitrary, since I basically decided one day that this was important, fixed the version to the oldest one that worked at the time, and promised never to break it from then on unless one of the unavoidable dependencies like html5ever or rust-url did. Since rust-url has similar guarantees of version hygiene, actually going all the way back to Rust 1.17, it’ll probably be html5ever that forces my hand.

        I’m not necessarily going to ask library authors to support a year-old version of a compiler that releases every six weeks, but please, for the love of all that is holy, test against a compiler version that isn’t the absolute newest one. Even if you only test against the current version + the immediately previous one (which is what I do for bors-ng, though it’s an application instead of a library), at least that way they can update at any time between Rust 1.36 and Rust 1.37 instead of being forced to update by your library. And once you have the process in place to support more than one compiler version, you’ve done most of the work necessary to adopt a less neophiliac policy than Newest - 1.

      3. 3

        It is reasonable to expect developers to have more or less a similar environment to yours. This is normally and best facilitated by the language’s package manager, which can fullfill library dependencies in a platform agnostic way (unlike distro package managers). At the time this is written, I have no expectations that every distribution’s package managers are ever going to catch up with all the libraries for every language. Like others, I used to have a delusion that my preferred language was mighty important and its libraries should be packaged in every major distribution.

        There seems to be a trend towards library version creep, too. A Debian stable or CentOS installation becomes virtually unusable for compiling C with CMake or with C++ in general because CMake and the C++ standard iterate much faster than aforementioned Linux distributions.

        1. 4

          because CMake and the C++ standard iterate much faster than aforementioned Linux distributions.

          Bug not feature. See also Node..

          1. 1

            I’ve been spoiled by OCaml’s package manager. I know other languages & their ecosystem don’t have such facilities or uniformity.

            1. 1

              How do you mean? Are you referring to OPAM?

              1. 1

                Yes and Dune (formerly Jbuilder).

          2. 2

            I see that you picked AppImage instead of Snapcraft, Flatpak, etc. Can you explain more about your reasoning?

            1. 1

              Things may have changed since I last reviewed the options, but I liked how AppImage handled the dependencies, without introducing other layers (virtualisation, sandboxing, etc). It was also not backed by any major interests at the time.