rebar3: add rebar3WithPlugins #119452
rebar3: add rebar3WithPlugins #119452
Conversation
| cth_readable = fetchHex { | ||
| pkg = "cth_readable"; | ||
| version = "1.5.0"; | ||
| sha256 = "BD81CDFBC9A3088621AA6AC4F20B5CEBC741D1E9C6B555F3F7D0369C9D59A87C"; |
There was a problem hiding this comment.
Please use base64 encoded hashes.
There was a problem hiding this comment.
These are generated by rebar3nix, however if base64 hashes are a requirement we could convert them
| patches = [ ./skip-plugins.patch ./global-plugins.patch ]; | ||
| })); | ||
| in stdenv.mkDerivation { | ||
| name = "rebar3-with-plugins"; |
There was a problem hiding this comment.
| name = "rebar3-with-plugins"; | |
| pname = "rebar3-with-plugins"; |
| PATH=${ | ||
| lib.makeBinPath [ | ||
| common-updater-scripts | ||
| coreutils | ||
| git | ||
| gnused | ||
| nix | ||
| (rebar3WithPlugins { }) | ||
| ] | ||
| } |
There was a problem hiding this comment.
| PATH=${ | |
| lib.makeBinPath [ | |
| common-updater-scripts | |
| coreutils | |
| git | |
| gnused | |
| nix | |
| (rebar3WithPlugins { }) | |
| ] | |
| } | |
| PATH=${lib.makeBinPath [ common-updater-scripts coreutils git gnused nix (rebar3WithPlugins { }) ]} |
| meta = { | ||
| homepage = "https://github.com/rebar/rebar3"; | ||
| description = "Erlang build tool that makes it easy to compile and test Erlang applications, port drivers and releases"; | ||
|
|
||
| longDescription = '' | ||
| rebar is a self-contained Erlang script, so it's easy to distribute or | ||
| even embed directly in a project. Where possible, rebar uses standard | ||
| Erlang/OTP conventions for project structures, thus minimizing the amount | ||
| of build configuration work. rebar also provides dependency management, | ||
| enabling application writers to easily re-use common libraries from a | ||
| variety of locations (hex.pm, git, hg, and so on). | ||
| ''; | ||
|
|
||
| platforms = lib.platforms.unix; | ||
| maintainers = lib.teams.beam.members; | ||
| license = lib.licenses.asl20; |
There was a problem hiding this comment.
| meta = { | |
| homepage = "https://github.com/rebar/rebar3"; | |
| description = "Erlang build tool that makes it easy to compile and test Erlang applications, port drivers and releases"; | |
| longDescription = '' | |
| rebar is a self-contained Erlang script, so it's easy to distribute or | |
| even embed directly in a project. Where possible, rebar uses standard | |
| Erlang/OTP conventions for project structures, thus minimizing the amount | |
| of build configuration work. rebar also provides dependency management, | |
| enabling application writers to easily re-use common libraries from a | |
| variety of locations (hex.pm, git, hg, and so on). | |
| ''; | |
| platforms = lib.platforms.unix; | |
| maintainers = lib.teams.beam.members; | |
| license = lib.licenses.asl20; | |
| meta = with lib; { | |
| homepage = "https://github.com/rebar/rebar3"; | |
| description = "Erlang build tool that makes it easy to compile and test Erlang applications, port drivers and releases"; | |
| longDescription = '' | |
| rebar is a self-contained Erlang script, so it's easy to distribute or | |
| even embed directly in a project. Where possible, rebar uses standard | |
| Erlang/OTP conventions for project structures, thus minimizing the amount | |
| of build configuration work. rebar also provides dependency management, | |
| enabling application writers to easily re-use common libraries from a | |
| variety of locations (hex.pm, git, hg, and so on). | |
| ''; | |
| platforms = platforms.unix; | |
| maintainers = teams.beam.members; | |
| license = licenses.asl20; |
| mkdir -p _checkouts | ||
| mkdir -p _build/default/lib/ |
There was a problem hiding this comment.
| mkdir -p _checkouts | |
| mkdir -p _build/default/lib/ | |
| mkdir -p _checkouts _build/default/lib/ |
| PATH=${ | ||
| lib.makeBinPath [ | ||
| common-updater-scripts | ||
| coreutils | ||
| git | ||
| nix | ||
| (rebar3WithPlugins { }) | ||
| ] | ||
| } |
There was a problem hiding this comment.
| PATH=${ | |
| lib.makeBinPath [ | |
| common-updater-scripts | |
| coreutils | |
| git | |
| nix | |
| (rebar3WithPlugins { }) | |
| ] | |
| } | |
| PATH=${lib.makeBinPath [ common-updater-scripts coreutils git nix (rebar3WithPlugins { }) ]} |
ofborg
bot
requested review from
gleber,
yurrriq,
happysalada,
ankhers,
Br1ght0ne and
DianaOlympos
|
Result of 1 package marked as broken and skipped:
3 packages built successfully:
Result of 1 package marked as broken and skipped:
3 packages built successfully:
5 suggestions:
|
|
I have to say, I don't use erlang, so I can't really produce valuable feedback on the general direction. I don't see anything that jumps out to me. Incidentally, you seem to be interested in nix and erlang, would you be interested in being part of the beam maintainers list? You can safely ignore Elixir related stuff if you're not interested and just focus on erlang stuff. As far as I know you would be the only erlang member active, so I don't think there would be too much extra work involved. That being said, no problem if you have other things to do. @hauleth you might be interested in this. @balsoft perhaps you know people in the nix community that use erlang and that this would be relevant to? |
|
Hi @happysalada, thanks for taking the time to look at this. I wasn't aware of the erlang-ls derivation you linked but I am aware of this one, which works very well. The problem with both of these is that they use something like fetchRebar3Deps, which relies on giving Thanks for the offer of being part of the beam maintainers list, I will have to read more about what this involves :). It is a shame to hear that I'm the only active erlang user! I think part of the problem might be that erlang is generally used to build bespoke (web) applications rather than packages that people would want to see packaged in |
|
Just a quick heads-up that I'm using buildRebar3 in my pleroma packaging: https://git.petabyte.dev/petabyteboy/nixfiles/src/branch/main/pkgs/pleroma/mixnix/mix2nix.nix#L129 |
|
@dlesl I like this new approach! I was thinking about doing something similar as the second attempt to get Erlang ecosystem in good shape in nixpkgs. Unfortunately my life path went away from Erlang world, so I do not have much motivation to work on it. Overall, I think this is the right direction! I find it hard to review this PR as it does a lot of things at the same time. I suggest the following steps:
[1] As of current state of |
|
@petabyteboy - I didn't explain it very well in the initial post but what I would like to see is that fetching deps individually becomes the standard way of building erlang packages with nix, so this shouldn't affect your usecase. If we get as far as modifying @gleber Thanks for the feedback and pointing me to Regarding handling deps, I see that
I was thinking we could patch rebar3 to ignore the It's hard for me to tell what's best here -- the bootstrapper approach is appealing in that it works with unmodified |
|
@dlesl I think the best near-term future is for both approaches to coexist in the The bootstrapper approach was used mainly due to an ability to use unmodified
Some upstream related issues: |
|
@gleber Thanks for providing some background here. I agree, it seems wrong to have Regarding the proposed solutions, I expect we will have to gradually move backwards from 5 (where we are now). If we can get a good solution working using 2-4 this would help make the argument to the rebar3 maintainers that our rebar3 patches are worth merging and maintaining. I still plan to update this PR (and make a PR to |
dlesl
force-pushed
the
rebar3-automated-packaging
branch
from
8e3c032 to
842b369
Compare
github-actions
bot
added
the
8.has: documentation
dlesl
changed the title
|
Should the buildPlugins attribute be removed from the buildRebar3 function as part of this? |
dlesl
force-pushed
the
rebar3-automated-packaging
branch
from
842b369 to
cd573f8
Compare
|
@ydlr rather than remove it I converted it to use |
| mkdir -p _checkouts | ||
| mkdir -p _build/default/lib/ |
| patches = [ ./skip-plugins.patch ./global-plugins.patch ]; | ||
| })); | ||
| in stdenv.mkDerivation { | ||
| name = "rebar3-with-plugins"; |
dlesl
force-pushed
the
rebar3-automated-packaging
branch
from
cd573f8 to
64fb916
Compare
dlesl
force-pushed
the
rebar3-automated-packaging
branch
from
64fb916 to
3682a84
Compare
|
This looks ready to be merged. Does anyone have any objections? |
This is an attempt to provide a system for packaging projects built with rebar3. It also aims to make it easier to use nix while working on a project. Before putting any more work into this I would be grateful for any feedback on the general direction!
As a demonstration I have used it to package
erlang-ls, as well as for packagingrebar3itself. The problems it solves areProviding a
rebar3WithPluginsderivationIt was necessary to patch
rebar3to achieve this, explanations of why are in comments in the code. You can use it like thisrebar3WithPlugins { plugins = [ beamPackages.pc ]; }.It would be more useful if we packaged more plugins. Building the
erlang_lsderivation complains about a few missing plugins but they don't seem to be essential for the build, still it would be nice to have them.Fetching/declaring dependencies without using
downloadPhaseThis is done by means of a small rebar3 plugin, which outputs a nix derivation. An example of usage can be seen in the updateScripts for erlang-ls and rebar3.
Work yet to do
Update 2021-05-07
For now I've reduced the scope of this PR to just adding
rebar3WithPlugins(see discussion in thread)