Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get rid of the BEAM package set #70524

Closed
DianaOlympos opened this issue Oct 6, 2019 · 5 comments
Closed

Get rid of the BEAM package set #70524

DianaOlympos opened this issue Oct 6, 2019 · 5 comments

Comments

@DianaOlympos
Copy link
Contributor

Issue description

Right now the BEAM package set snapshot is left without maintenance and update since 2018. The BEAM community have move to lock files handled by its build tool (mainly mix and rebar3). With the deployment of sandboxing, the hermetic build of rebar3 patched for Nix has been abandoned and deleted in #54115 .

Following #54115 and #53834 and also https://discourse.nixos.org/t/state-of-the-beam-ecosystem-in-nix/4202/, it seems obvious that the BEAM community do not expect this to continue. There have been multiple tentative and work in progress to build a tool to incorporate these build tools lockfile into nix. And flakes may help on the long run.

While the community is coalescing around a long run solution, I would like to get rid of the package set and the associated functions, and update the documentation to explicitly state that you need to download dependencies by hand without sandboxing. This is already what everyone is doing due to the age of the snapshot of hex. Better get rid of the maintenance burden.

I am interested in hearing reasons to not do so and help around how to word this and alert users of possible break in their build. I doubt it will affect too many people.

@DianaOlympos
Copy link
Contributor Author

cc @ankhers @gleber possibly ?

We are using the BEAM on Nix in production right now and we would like to help the state of the ecosystem to be a bit nicer for everyone 😃

@gleber
Copy link
Contributor

gleber commented Oct 6, 2019

@DianaOlympos I support this step. That's the right thing to do.

@ankhers
Copy link
Contributor

ankhers commented Oct 6, 2019

I agree. It should be removed.

@DianaOlympos
Copy link
Contributor Author

Ok i will take a try at it later this week and open a PR. I bet this one is going to be painful...

@DianaOlympos
Copy link
Contributor Author

#71393

@Mic92 Mic92 closed this as completed Nov 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants