We’ve recently open-sourced some Erlang packages. At the moment, they’re just pushed to GitHub.
I’d like to publish them to hex.pm – if nothing else, to prevent someone squatting on the names.
What’s the best practice for setting up a hex.pm account for an organization? I’m thinking about allowing multiple people to publish new versions of the package, and – worst case – if I leave and have to hand over control of the packages.
I host private packages on Hex as an organisation and it’s an excellent and reliable service that is fairly priced.
I wrote an energy calculation engine in Elixir, and having access to different hosted versions has made my working life much less stressful. I’m sure there are other ways to do it, with Git submodules etc, but I really like being able to develop the engine independently without breaking the other codebases that have it as a dependency.
PS: If I had one suggestion is that hex.publish recognise the non-American spelling of “organisation” such that one doesn’t accidentally publish a private package! (There is good feedback during the deploy such that you can check the version and visibility.)
Which part? I’m producing PDF reports in Typst in another Elixir application using the results of the energy calculation and they need to be versioned. Knowing which version of the energy calculation I’m depending on, makes that much more clear cut.
The energy calculation engine itself depends on another private module that models gas boilers and heat pumps, etc, from a public database that is updated every month. That also needs to be versioned, since the energy efficiency of a boiler may be updated.
If I need to produce legacy reports if, say, I have designed a new report format, I can depend on an earlier version of the calculation engine. Since advice will have been signed off by contractors, I do want to see what the advice was at a point in time.
Of course, one could also use event sourcing, but with private Hex repositories, I get the level of change granularity I need. I also have to account for different fuel prices over time and different upgrade measure recommendations with their pricing.
I didn’t say that hex orgs are unreasonably priced. I just said it’s a paid feature because for open source projects you usually don’t move ahead immediatelly aggregating recurring costs – to the contrary.
It was not clear to me how is using a private Hex repo helpful in using separate (older) versions in other projects, and still is not. Nothing that can’t be done with the free version I’d think.
Thanks for elaborating on the rest, interesting read actually.
Hex organizations are free if you only use them for public packages, only when you need private packages is billing required.
If you have multiple packages organizations makes it easier to manage users and permissions since you can manage them for the whole organization and all its packages instead of each package individually.