* mixRelease: format code by nixpkgs-format
* mixRelease: investigate why erlang is referenced in resulting derivation
* mixRelease: organize nativeBuildInputs and buildInputs
It:
+ organizes `nativeBuildInputs` in a structured way.
+ moves `builtins.attrValues mixNixDeps` to `nativeBuildInputs`, because it's only used in compile-time
* mixRelease: remove current attempt for removing erlang references in resulting derivation
As said in the comment about "remove erlang references in resulting
derivation", for now, we don't have a robust method to do that.
Although these removed code did some work, they did not achieve the
final goal - remove erlang references in resulting derivation.
Therefore, it is better to remove them and provide future implementation
with a clean foundation.
> If you want to find these old codes, you can also retrieve them from
> the git history.
* mixRelease: remove all files for Microsoft Windows
* mixRelease: add new option - `removeCookie`
* mixRelease: polish comments
+ Capitalize the sentences.
+ Add punctuation marks.
+ Format a little code.
* mixRelease: wrap programs in $out/bin with their runtime deps
* mixRelease: commit what happysalada suggests
---------
Co-authored-by: c4710n <c4710n@users.noreply.github.com>
Avoid the following during mix releases:
```
warning: the VM is running with native name encoding of latin1 which may
cause Elixir to malfunction as it expects utf8. Please ensure your
locale is set to UTF-8 (which can be verified by running "locale" in
your shell)
```
This flag appears to cause issues in 3 out 4 users of mixRelease in
Nixpkgs, plus Mobilizon, which isn't merged yet. It might be safer to
set it to fals for now, as the runtime error messages produced by it are
quite cryptic.
The Elixir LS package in Nixpkgs by default used the latest Elixir
version available to compile and run Elixir LS. The user can build
a custom Elixir LS package with a different Elixir version:
my-custom-elixir-ls = pkgs.elixir-ls.override {
elixir = my-custom-elixir;
};
But by doing so the user changes only the Elixir version used to
run Elixir LS; the Elixir version used to compile Elixir LS doesn't
change. As the result, the custom Elixir LS package uses a different
Elixir version at runtime than the Elixir version it was compiled with.
In order to be able to modify the Elixir version used at build time,
I changed `mixRelease` and `fetchMixDeps` to accept `elixir` and
`hex` as parameters (defaults to the latest Elixir and Hex packages).
