Problem with dependencies

[dimitarvp]

@joeerl

So something is wrong but what?

Looking at Elixir’s changelogs and inferring the general direction from them and by the core team’s posts, I would say they want to make Elixir even more explicit. I believe this thread is partially related to your valid misgivings:

PSA: Do not use private APIs, request a feature instead

Hi everyone, With the v1.7 release, we have received reports of some dependencies no longer working properly on the new release. Developers should not expect breaking changes from Elixir on minor and patch releases. We outline our compatibility and deprecations policy in our docs: Compatibility and Deprecations — Elixir v1.15.2 This means that, if there is something effectively broken in a new release, it is one of: We messed up and accidentally introduced a regression, which we have to fix …

Trouble with most open-source is that people start off doing it enthusiastically and it either (a) achieves the original goal of the author, or (b) they got burned out and/or got swamped with other duties and can no longer maintain the package.

Elixir does not introduce breaking changes as far as I am aware but bugs in older versions existed and some libs / apps might have worked because of them and not in spite of them. Somebody once said: “Computer bugs are like dogs: they like lying on their bellies in the company of their kin.”

@joeerl

Describing a version by a number like 2.0.2 is in my mind crazy - I’d prefer the system to be described by a list of the SHA1 checksums of all the modules needed to reproduce the behavior of the program.

I agree and have been waiting on a programming language tool to introduce something as strict. We absolutely need builds reproducible to the last byte. The closest you can get with mix and hex is to do this (taken from here):

{:foobar, git: "https://github.com/elixir-lang/foobar.git", tag: "0.1"}

If the author has good version control hygiene they will have stable tags and as we know, Git tags are basically pointers to a commit hash.

@joeerl

I’ve written a garbage collector for Erlang dependencies - basically it takes a root set of function calls and traces everything that can be called renaming appropriately and putting everything into a single module.

It is high time that all languages have this. Given an import ThisModule, only: [:function1, :function2] statement, I believe the compiler should go a few hundred extra miles to make damn sure to only include those functions and everything they depend on directly, in the resulting .beam file. Not so easy with runtime dynamic programming though (say you are passing a module as a function parameter for example, and that parameter depends on user input which cannot be predicted beforehand). Or this can be an extra mode for the mix xref command which is mighty useful and helped me refactor with great success several times now.

@joeerl

and the program will work just like it did 1000 years ago

Many of us want that but the dependency in question might work perfectly under Elixir 1.4.0 and break under Elixir 1.7.2. Having a singular deployable application entity (with sub-applications and libraries bundled in) whose separate parts depend on different versions of the language/runtime is a problem that nobody wants to tackle, and rightfully so.