Building Erlang Projects Offline

Fred Hebert mononcqc@REDACTED
Mon Feb 21 18:42:10 CET 2022


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.


More information about the erlang-questions mailing list