Re: Building Erlang Projects Offline

I had a draft started with these points from Fred before seeing this :)

I'll add that there have been ongoing discussions about offline bootstrapping and general offline/vendoring support in the build and packaging WG, https://erlef.org/wg/build-and-packaging

Those interested should join us there and help move a solution forward.

Ericsson had or has someone working on at least the bootstrap issue but I don't know where that is at the moment.

Part of my day job is still Erlang, but only open source stuff, so no need for this functionality -- at least not by any current customer base that is using the open source libraries and our service.

Tristan

On Mon, Feb 21, 2022, at 10:42, Fred Hebert wrote:
> 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.