Re: Building Erlang Projects Offline
Fred Hebert <[email protected]> Mon, 21 Feb 2022 12:42:10 -0500
| Newsgroups | gmane.comp.lang.erlang.general |
|---|---|
| Message-ID | <YhPO8gfW9Uhiv/[email protected]> |
On 02/21, Oliver Korpilla wrote: > >Frankly, this whole "package management by default" is a real hassle if >you want to go offline. The hoops I had to jump through so that nothing >gets downloaded from the internet were more effort than we ever anticipated. > >Oliver > While I understand the general frustration, the general expectation at the time of design (now 6+ years ago) was that people would generally do what was popular at the time: set up their own private mirrors for all dependencies, whether git-based on hex-based. That sort of stuff should be supported right now. The vast majority of most recent developments have shifted outside of that design into one of flat source vendoring, or some variation thereof. The challenge we've had since then is in trying to corral all the sorts of requirements various people have, and it's an unwieldy mess: - Some people do want the mirroring (though they're smaller now than before) - Some people want a monorepo where they maintain patch sets and continuously update the libraries as non-public variations - Some people want a regular project but with an offline mode where dependencies are not expected to change - Some people want to also version Erlang versions themselves and be able to configure these paths - Some people will want all the files to be turned into system-wide, versioned libraries that can be used across projects in unison - Some people require interoperability with other cross-language build tools - Some people will want a mix of these various options, but all of them do need to be offline. And here by 'people', I tend to mean 'pwople working at corporations who also happen not to really be able to share the code of their projects.' The general end result of this is that many of the proposals we get for a change or a patch set does the bare minimum people need for their use case, and often in ways that wouldn't work great with existing design or other use cases. Absorbing maintainership for that hasn't felt very interesting. The last bit is the unsurprising necessary disclaimer: Rebar3 is maintained by two people who do it in their free time. I personally do not even work with Erlang as a software engineer anymore and have moved on to the role of SRE (for unrelated reasons -- now Erlang is a hobby I enjoy again). Tristan does have his own schedule as well. This is the sort of project that is frankly unlikely to see major progress when done as a hobby, because it's specifically a corporate-driven sort of feature that most users at home never encounter, at least until the bill-of-materials US legislation somehow extends to side project done in your free time. For me personally (I can't talk for Tristan here), I'm unlikely to start doing multi-organization corporate-style project development in my free time, unpaid, just for the sake of it. I have hobbies that interest me more. I am however willing to guide or help design bits of it, because I do understand that the sort of domain-specific knowledge around everyone's builds has been concentrated in a few of us over the last few years. Regards, Fred.