4 ms·

Agner: A Giant Nebula of Erlang Repositories

35 points by yrashk 16y ago

davidw 16y ago
About damn time for Erlang to be getting this kind of thing. Ruby is not "all that" in terms of performance or its concurrency story, but Erlang feels a bit like the stone ages without all the nice gem stuff.
- yrashk 16y ago
  well, no more — agner is pretty much providing a seamless experience to erlang users. For example, in order to use entop command line utility, you had to clone two repos, build both of them and use that script from the directory where you built entop. And lots of erlang packages are like that. With agner, you just do $ agner install entop and you're done, it's in your PATH
deleted 16y ago
[deleted]
- yrashk 16y ago
  I very much hope so, and I understand that it takes much more than writing software — it's also promotion, maintenance and so on; also integration with existing tools (like rebar).
  - kunley 16y ago
    Whoops, i mistyped and accidentally deleted my comment. Anyway, good luck!
    - yrashk 16y ago
      Thanks!
kunley 16y ago
One thought.. is it really necessary to create separate repository just for holding agner.config file? Can't author just add this file to his original repo and move on?
- yrashk 16y ago
  There are multiple reasons for this architecture: 1. central index/indices 2. granular overlaying (you can overlay specific packages and don't have to maintain your fork of a global repo) 3. granular permissions, allowing maintainers to work on their packages without going through the hassle of pull requests and associated bottleneck problems (the "homebrew problem") 4. usage of tags and branches for versioning primitives 5. independence from original repository 6. ability to use multiple repositories 7. (in the future) ability to use non-SCM fetching methods (aka "tarball") That's for starters. Good enough? :)
  - kunley 16y ago
    Well I can see your motivation and technical background. The question is: will coders bother ;) It's the people who finally decide so you'll probably have your bit of advertising/explaining to the community..
    - yrashk 16y ago
      Most of people I talked to seem to be ok with this; also it only is important for those who decide to maintain or create their own packages — agner users don't have any hassles with it. And it's not that bad anyway :) — plus if the package author doesn't want to bother, he doesn't have to — anybody can submit a specification.
      - kunley 16y ago
        That's cool.
dennyabraham 16y ago
how does this compare to a system like https://github.com/erlware/faxien https://github.com/erlware/faxien ?
- sofuture 16y ago
  There does seem to be a bit of a community fracture between rebar-centric-world and Erlware-world. I'm not sure I really understand it's origins, or why it persists. It would absolutely benefit Erlang to heal over this gap -- not that having separate tools is a bad thing at all, but the fact that both ecosystems often seem so blissfully unaware of the other :)
- kunley 16y ago
  The reality check: for the most of github-hosted erlang projects no one seems to use erlware..

35 points by yrashk 16y ago

About damn time for Erlang to be getting this kind of thing. Ruby is not "all that" in terms of performance or its concurrency story, but Erlang feels a bit like the stone ages without all the nice gem stuff.

yrashk 16y ago
well, no more — agner is pretty much providing a seamless experience to erlang users. For example, in order to use entop command line utility, you had to clone two repos, build both of them and use that script from the directory where you built entop. And lots of erlang packages are like that. With agner, you just do $ agner install entop and you're done, it's in your PATH

deleted 16y ago

[deleted]

yrashk 16y ago
I very much hope so, and I understand that it takes much more than writing software — it's also promotion, maintenance and so on; also integration with existing tools (like rebar).
- kunley 16y ago
  Whoops, i mistyped and accidentally deleted my comment. Anyway, good luck!
  - yrashk 16y ago
    Thanks!

kunley 16y ago

One thought.. is it really necessary to create separate repository just for holding agner.config file? Can't author just add this file to his original repo and move on?

yrashk 16y ago
There are multiple reasons for this architecture: 1. central index/indices 2. granular overlaying (you can overlay specific packages and don't have to maintain your fork of a global repo) 3. granular permissions, allowing maintainers to work on their packages without going through the hassle of pull requests and associated bottleneck problems (the "homebrew problem") 4. usage of tags and branches for versioning primitives 5. independence from original repository 6. ability to use multiple repositories 7. (in the future) ability to use non-SCM fetching methods (aka "tarball") That's for starters. Good enough? :)
- kunley 16y ago
  Well I can see your motivation and technical background. The question is: will coders bother ;) It's the people who finally decide so you'll probably have your bit of advertising/explaining to the community..
  - yrashk 16y ago
    Most of people I talked to seem to be ok with this; also it only is important for those who decide to maintain or create their own packages — agner users don't have any hassles with it. And it's not that bad anyway :) — plus if the package author doesn't want to bother, he doesn't have to — anybody can submit a specification.
    - kunley 16y ago
      That's cool.

dennyabraham 16y ago

how does this compare to a system like https://github.com/erlware/faxien https://github.com/erlware/faxien ?

sofuture 16y ago
There does seem to be a bit of a community fracture between rebar-centric-world and Erlware-world. I'm not sure I really understand it's origins, or why it persists. It would absolutely benefit Erlang to heal over this gap -- not that having separate tools is a bad thing at all, but the fact that both ecosystems often seem so blissfully unaware of the other :)
kunley 16y ago
The reality check: for the most of github-hosted erlang projects no one seems to use erlware..