diff options
| -rw-r--r-- | posts/elm-everything-broken.md | 143 |
1 files changed, 96 insertions, 47 deletions
diff --git a/posts/elm-everything-broken.md b/posts/elm-everything-broken.md index 6e86cf6..a9978d1 100644 --- a/posts/elm-everything-broken.md +++ b/posts/elm-everything-broken.md @@ -1,12 +1,11 @@ Title: Everything Is Broken (Installing Elm Edition) Author: bnewbold Date: 2016-05-06 -Status: draft *This post is a narrative rant (in the same vein of Dan Luu's ["Everything is Broken"][danluu] post) about my problems one afternoon getting a Fancy New -Programming Language to work on my laptop. Skip to the end for my thoughts on a -solution.* +Programming Language to work on my laptop. [Skip down](#nowwhat) for my +thoughts on solutions.* [danluu]: https://danluu.com/everything-is-broken/ @@ -20,7 +19,8 @@ solution.* A few folks here at the [Recurse Center][rc] had nice things to say about the [Elm programming language][rc], and after watching Evan Czaplicki's ["Let's Be -Mainstream" talk][0] I got pretty excited also. Let's try Elm! +Mainstream" talk][0] I got pretty excited also. "Let's try Elm!" and the +adventure begins. [rc]: https://recurse.com/ [elm]: https://elm-lang.org @@ -52,9 +52,9 @@ get `cabal` set up, open a terminal and paste a command, etc? --> Weird that these build-from-source directions involve curl-to-file magics. Why not just clone the repo and use a Makefile, which is roughly the same number of -commands to enter? I clone repo and run the script from there instead. I'm on -Debian stable ("jessie"), so installing GHC (the most popular way to use -Haskell) is easy. I seem to have a recent version of cabal: +commands to enter? I clone repo and run the build script from there instead. +I'm on Debian stable ("jessie"), so installing GHC (the most popular way to use +Haskell) is easy. I seem to have a recent-ish version of cabal: <pre class="terminal"> bnewbold@eschaton$ cabal --version @@ -80,8 +80,9 @@ GHCi cannot safely continue in this situation. Exiting now. Sorry. </pre> Uh-oh! Not sure what that means. A search returns [a FAQ entry][faq-entry] -about "Duplicate Directions". It doesn't seem like *I* have done anything -wrong. I'll update `cabal`'s package index: +about "Duplicate Directions" which talks about linker flags, but *I* didn't +compile anything by hand so it doesn't seem like *I* have done anything wrong. +I'll try updating `cabal`'s package index: [faq-entry]: https://wiki.haskell.org/GHC/FAQ#Duplicate_Definitions @@ -93,8 +94,8 @@ http://hackage.haskell.org/packages/archive/00-index.tar.gz : ErrorMisc "Error HTTP code: 502" </pre> -At first I assumed I was doing something wrong, or maybe the WiFi was flakey, -but it turns out that the Hackage package repository [is +No go! At first I assumed I was doing something wrong, or maybe the WiFi was +flakey, but it turns out that the Hackage package repository [is down](https://status.haskell.org/): > hackage.haskell.org down @@ -105,13 +106,13 @@ down](https://status.haskell.org/): <div class="sidebar"> As far as I know, the only Debian packages out of the huge stable archive which -don't receive security updates are a set of web browser, mediawiki, and all -V8/node.js packages and libraries. +don't receive security updates are web browsers, mediawiki, and all V8/node.js +packages and libraries. </div> -Well, wasn't even sure if updating my package index would fix the problem. I'll -give up and try npm, which these days has been [sort of -packaged][deb-node] in Debian. I'll just uninstall npm when I'm done +Well, it wasn't even clear if updating my package index would fix the problem, +it was just a wild guess. I'll give up and try npm, which these days has been +[sort of packaged][deb-node] in Debian. I'll just uninstall npm when I'm done installing Elm. I install with `apt` (which pulls in a huge list of `nodejs` packages), but then can finally run: @@ -161,8 +162,8 @@ package, which just installs a symlink /usr/bin/node which points to /usr/bin/nodejs. </div> -Looks like Debian wants to call node.js `nodejs` while npm/Elm expects it to -be called `node`. Ok, I create this shim named `node` in my `~/bin` directory +Looks like Debian wants to refer to node.js as "`nodejs`" while npm/Elm expects +it to be "`node`". Ok, I create this shim named `node` in my `~/bin` directory (which is on my `$PATH`), and make it executable: <pre class="terminal"> @@ -218,8 +219,8 @@ npm ERR! not ok code 0 Whoops. There is [a github issue][elm-issue] that has some tips about this: the recommended solutions online are basically "upgrade node.js and npm" or "disable SSL security". That doesn't sound great, but i'm feeling very -impatient at this point so I tried disabling SSL checks with npm config set ca -null`, but even then I get the same certificate error. Enough of that approach: +impatient at this point so I tried disabling SSL checks with `npm config set ca +null`, but even then I get the certificate error. Enough of that approach: [elm-issue]: https://github.com/elm-lang/elm-platform/issues/100 @@ -232,21 +233,21 @@ Poking around a bit more, I find the promisingly-titled "`fubar.sh`" script in the `elm-platform` repo cloned earlier, which seems to nuke the local user's Haskell (`cabal`) stuff (but doesn't muck with system-wide package, eg `apt` managed GHC libraries). After running `fubar.sh` the `BuildFromSource.hs` -script seems to start working, though Hackage is still down (now, an hour after -I started this process, approaching 5 hours total downtime), so I can't install -dependencies. +script seems to start working (success!), but Hackage is still down (now, an +hour after I started this process, approaching 5 hours total downtime), so I +can't install dependencies. I search for a hackage mirror and find that [FPComplete runs one](https://www.fpcomplete.com/blog/2015/03/hackage-mirror). In addition to -their directions I had to set `remote-repo-cache` in my `~/.cabal/config`, like -so: +their configuration instructions I had to set `remote-repo-cache` in my +`~/.cabal/config`, like so: remote-repo: hackage.fpcomplete.com:http://hackage.fpcomplete.com/ remote-repo-cache: /home/bnewbold/.cabal/packages-fpcomplete After that I `cabal update` and run the `BuildFromSource.hs` script again. It fails to build the dependency `websockets-snap`, but I try installing that -regularly (`cabal install websockets-snap`) and that works, then all the +regularly (`cabal install websockets-snap`) and that works, and then all the dependencies with BuildFromSource.hs build. Yay! I still get an error with compiling Elm itself though: @@ -259,8 +260,8 @@ It [sounds like](https://github.com/elm-lang/elm-platform/issues/30) I am using an out of date version of GHC (the Haskell compiler): I have 7.6.3 (the version that comes with Debian), and Elm wants 7.10. Fair enough: unlike a package manager, I can see how new features in the compiler would be helpful, and when -I go back and look this is in the README. Fortunately there is a new version of -GHC in the `jessie-backports` repo, so: +I go back and check this was outlined in the README. Fortunately there is a new +version of GHC in the `jessie-backports` repo, so: <pre class="terminal"> sudo apt install -t jessie-backports ghc @@ -289,32 +290,44 @@ bnewbold@eschaton$ elm-repl Success! -Throughout this debugging experience I had problems with both my external -[Lenovo Thinkpad USB keyboard][keyboard] glitching (workaround: unplug and -re-plug) and with WiFi at the Recurse Center disconnecting (workaround: reset -wifi card). Others here using GNU/Linux have the same wifi problems, but we -don't have a fix yet... something to do with wireless regulatory zones. +To be clear, once I got this far I had few or no problems with Elm. The +language seems reasonably clean and well documented for it's maturity, and it +was only this install procress that felt horribly broken. + +Throughout this debugging process I had problems with both my external [Lenovo +Thinkpad USB keyboard][keyboard] glitching (workaround: unplug and re-plug) and +with WiFi at the Recurse Center disconnecting (workaround: reset wifi card). +Others here using GNU/Linux have the same wifi problems, but we don't have a +fix yet... something to do with wireless regulatory zones. It's not all pain though; installing the `elm.vim` syntax highlighting plugin was very easy, just a single `git clone` into `~/.vim/bundle/`. [keyboard]: https://www.amazon.com/Lenovo-ThinkPad-Compact-Keyboard-TrackPoint/dp/B00F3U4TQS +<a name="nowwhat" /> + So Now What? ---------------- -TODO: dan's auto-testing tips - -There was a great long-form blog post by Same Boyer a few months ago -(["So You Want To Write a Package Manager"][5]) which discussed Rust's package -manager, Cargo. - -[Yehuda Katz and Carl Lerche][6] designed Cargo. - -Ironically, given the difficulty I had installing it, the Elm language's +There was a great long-form blog post by Sam Boyer a few months ago ("[So You +Want To Write a Package Manager][5]") which describes the jumble of *system*, +*language*, and *project* dependency manager problems I experienced above. Sam +basically concludes that Rust's project/language dependency manager (Cargo) +both encapsulates best practices for dependable and reproducible builds, while +still allowing rapid evolution of a package "ecosystem". Cargo was designed by +[Yehuda Katz and Carl Lerche][6], and along with the +[crates.io](https://crates.io) archive it does sound very nice. My personal +feeling are usually that system-wide package managers (like Debian's `apt`) are +underappreciated by many young-but-not-bleeding-edge projects, but acknowledge +that there probably is also a need for higher tempo cross-platform project +dependency mangement for non-library projects (eg, desktop applications and web +apps). + +Ironically (given the difficulty I had installing it), the Elm language's package manager has a great `diff` tool for checking that any changes in the -API conform the [documented][8] [semantic versioning][semver] conventions. For -[example](https://gist.github.com/badboy/a302dd0c9020e5759240): +API conform to the [documented][8] [semantic versioning][semver] conventions. +For [example](https://gist.github.com/badboy/a302dd0c9020e5759240): $ elm-package diff evancz/elm-html 3.0.0 4.0.2 Comparing evancz/elm-html 3.0.0 to 4.0.2... @@ -335,9 +348,44 @@ API conform the [documented][8] [semantic versioning][semver] conventions. For defaultOptions : Html.Events.Options onWithOptions : String -> Html.Events.Options -> Json.Decode.Decoder a -> (a -> Signal.Message) -> Html.Attribute -This change information is then used to *[programatically enforce][7]* the -versioning rules and prevent a whole class of simple but annoying breakages -due to API change. +This API change information is then used to *[programatically enforce][7]* the +semantic versioning rules for submissions to the Elm language library archive +and prevent a whole class of simple but annoying breakages due to unexpected +API changes. It can't detect *every* breaking change (eg, those which are +internal), but it can detect enough to be worth the effort. + +Another option for detecting fixing breakage is integration testing at the +package ecosystem level. Debian's [reproducible builds][repro] effort has built +out one such system, and continues to catch thousands of "failed to build from +source" (FTBFS) bugs along the way. Dan Luu's ["Everything is Broken"][danluu] +blog post (which to some degree inspired this one) mostly focused on the lack +of quality tests for many contemporary software projects, and proposed the use +of smart fuzzing and heuristically-generated tests to work around the huge +technical debt this represents. As far as I can tell there are hardly ever +automated integration tests for entire package archives; blame for dependency +problems is usually attributed to a bug in one package (instead of being seen +as a systemic failure), and such problems are seen as an unavoidable cost of +rapid and distributed development. + +I think we can do better. For example, some contemporary languages test +compiler changes for regressions against a broad snapshot of public code +written in that language; I know Go and Rust specifically do this to identify +problems before compiler releases, and the Python community occasionally runs +tests against the PyPi archive when considering syntax changes or feature +deprecations. And Debian's unstable and testing archives enforce a waiting +period so that human testers can turn up conflicts before packages can be moved +into stable or backports. I think we can and should automate these processes as +much as possible, and give direct feedback to library developers and package +maintainers when they push updates. Commercial Continuous Integration services +like Travis CI and Circle CI should offer more common target platforms (eg, ARM +architecture, more versions of distributions), and if they don't we should +build and host our own testing infrastructure. CI builds scripts should closely +match the official installation instructions for a given platform, so we catch +problems with those instructions quickly. + +We have more and more developers in the world wasting more and more days +wrangling with dependency hell, but despite that I think we're closer than ever +to taming the beast. [5]: https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527 [6]: https://mail.mozilla.org/pipermail/rust-dev/2014-March/009090.html @@ -345,6 +393,7 @@ due to API change. [8]: https://github.com/elm-lang/elm-package/blob/master/README.md#publishing-updates [semver]: http://semver.org/ [appcheck]: http://www.linuxfoundation.org/collaborate/workgroups/lsb/linux-application-checker-getting-started +[repro]: https://tests.reproducible-builds.org/debian/reproducible.html <hr /> |