HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
gdotdesign
elm-github-install
Ruby2020–2023
gdotdesign / elm-github-install

elm-github-install

An alternative decentralized package manager for Elm

9Distinct people
10Mentions
0Explicit recommenders
207GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

An alternative decentralized package manager for Elm

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:27:21 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year10 dated mentions

Observed mentions: 2020-04-09 19:17:11 UTC to 2023-11-20 16:18:52 UTC.

012342020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2023

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC404
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC202
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC404

What Hacker News says

4 sources
I've invested a lot of time in Elm about two-to-three years ago, the two main things was elm-ui [1] and elm-github-install [2]. At the time elm-ui was impossible to build without "native code" so I used it and built elm-github-install to make it work. Suffice to say, I've run into the exact same issues as the author. Had they allowed me to contribute in a meaningful way Elm now would have a nice UI library and probably a much nicer package website which I've developed as well [3] (no longer running, but I've turned maintenance mode off for a few days so you can take a look). I stopped using and contributing to Elm when 0.19 came out. If you are interested how much effort I put in just check the Elm related repositories in my Github profile [4]. After that I missed the developer experience and I created Mint [5], so in the end some of know
Read the rest
ledge I gathered during that time have been put to good use :) I just can't understand how they could ignore all the work I've put in, if someone would invest that much time and effort into Mint (or any open source project of mine) I would welcome it and or at least start a dialog on how we could integrate their work into the language. Anyway, I thought I share my Elm story with you (although probably a bit late :)) Cheers [1] https://github.com/gdotdesign/elm-ui [2] https://github.com/gdotdesign/elm-github-install [3] http://elm-directory.herokuapp.com/ https://github.com/gdotdesign/elm-directory [4] https://github.com/gdotdesign?tab=repositories&q=elm-&type=s... [5] https://www.mint-lang.com/ https://github.com/mint-lang/mint
In Why I’m Leaving Elm
> But he didn't ask for work to be done anywhere in the article? He asks that he not be prevented from writing code that the compiler supports, but which is arbitrarily limited to members of certain organizations. That's not asking for work. But that is asking for work! That's a great example of "why don't you just... $TRIVIAL" where $TRIVIAL = "turn off the restrictions", as if there is no consequent problem for the upstream author to have to figure out how to achieve the design goals of the project afterwards, or manage the explosion in issues with modules that may potentially emerge, or who knows which other concerns (I'm just throwing out some guesses; don't take them seriously.) It's a great example of what Evan describes in the video, of a seemingly trivial request whose potential complex consequences are not seen by the requestor,
Read the rest
but are seen and must be dealt with by others; and of conflicting priorities. Essentially it is a request to the author: "I ask that you spend time to revise your design to figure out how to allow my module's techniques to keep working at the same time as achieving the design goals of Elm going forward, and reverse your design decision that you have already made". > I feel like if you make it so that users of your platform cannot do certain work for themselves, and instead must await you doing the work, you are basically creating the entitlement. You now owe it to them, in some sense, to do the work, since you have intentionally blocked them from doing it themselves. You have not blocked them. As many commenters have pointed out, you don't have to wait, you can fork. You can fork quietly if you don't want social issues from making a big noise, as vast numbers of developers do with a vast numbers of projects. If the upstream author is not making it easy for the downstream module author, perhaps requiring the downstream author to maintain a patched version of the compiler and persuade other people to use the patch, tough. There's isn't and shouldn't be any moral obligation on the upstream to screw their design goals to accomodate that particular downstream author. I've had to maintain patched Linux kernels for a project. I didn't resent Linux upstream for that. I didn't complain that I needed to patch the kernel. It was just part of the cost of doing my project. It limited what I could expect to do, but I went into it informed of what to expect. > it's plain that there is a certain slice of the population who doesn't prefer this paternalistic approach to software tools. I agree. It's more than prefer for some. A certain slice almost demands it and makes life hard for any author who does not provide. For which the word is "entitlement". Unfortunately that slice has a subslice who wants something self-cancelling: A non-paternalistic project that talks with them at length patiently, accomodates most requests no matter how varied and contradictory, yet still produces a coherency of design, magic-sauce artefact for them, preferably on a regular release cycle with QA, with nobody's time and personal needs covered. In other words, what they want isn't always feasible, yet they still demand it from individuals (often via emotional pressure), rather than start their own projects. > Personally my advice is if you're not into opinionated BDFLs blocking you from doing things for non-technical reasons, don't use ecosystems controlled by BDFLs I agree wholeheartedly. And that's the advice given to Luke by an Elm developer in 2018! :- https://github.com/gdotdesign/elm-github-install/issues/62#i... Sounds like Luke chose to ignore the advice, then was angry 1.5 years later. I think it can be argued that the person ignoring the advice is the one who creates the later problem for themselves. > If the Evans of the world wish to remain atop their ivory tower, then they will be the recipients of an incrementally higher frequency of rage-quit posts as a result. Should doesn't enter into it. That's just how it is. I think that comes under excusing abuse by saying it's inevitable that someone will do it. Public rage-posts about someone's work are still abuse if the basic problem is that the other person didn't do what you wanted them to. What we should have, in a "good" world, is that people like Evan should be able to produce their projects in relative peace without abuse. If people don't like the project, in the "good" world people know what to expect and are free to start their own alternative. I think the Evans of the world lose in our current world, no matter what they do. If they are less paternalistic, they will have both an ever-increasing workload until they step down, and the project will not fulfil their design wishes so it's much less rewarding.
In Why I’m Leaving Elm
The bit about "excommunication" is very explicitly linked to the author's plan to fork Elm. Now, I don't think "excommunication" is necessarily the correct descriptor. The Elm maintainer who made the threat said that he considered making a fork on "attack" on Elm's goals [1], and that the project would not be greeted with open arms. (Although in the original comment it was a little less clear whether it was the project or the person to whom arms would not be open.) In any case, I think the comment is very clear that the hostility is to the action of forking, irrespective of previous communication problems. [1]: https://github.com/gdotdesign/elm-github-install/issues/62#i...
In Why I’m Leaving Elm

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.