<div dir="ltr"><div>I would think the Erlang community would want to own their package manager so it can be made to fit, potentially written in the language the community uses. But if you want to use an existing wheel, why not a wheel that runs on all planned roads, like f.ex. NPM (Node Package Manager) vs Nix that doesn't run on Windows and I understood just started on MacOS. NPM has bee used by a larger, much more varied community then the Erlang community so if not using a fork of NPM then there are at least a lot of lessons leaned there.</div><div><br></div><div>-Mark</div><div><br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 2, 2015 at 12:26 PM, Richard Jones <span dir="ltr"><<a href="mailto:rj@metabrew.com" target="_blank">rj@metabrew.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Great to hear the IEUG and the OTP team are giving this some attention - please post a summary of what you consider the important points are, once the dust settles :)</div><div><br></div><div>Two main concerns from me: the nature of the repo/api/tools, and appup related stuff.</div><div><br></div><div><br></div><div>My instinct would be to first copy or design a well behaved HTTP api for a package repo, along with defining the relevant package metadata format (an extension of .app files, perhaps).<br></div><div>With any luck, this will mostly be just a bunch of files on disk in a special directory structure.</div><div>Then expose an HTTP search interface that indexes the metadata.</div><div>Make sure it's easy to clone/mirror and run your own private package repository or a copy of the main one (eg: rsync, then trigger a reindex)</div><div>Then build tools that use the aforementioned HTTP API.</div><div>Pushing a new version of a package I author should make it publicly visible without undue delay.</div><div><br></div><div>Although I'm reasonably content with things like rebar that depend on stuff on github, copying the packages to a central repo is still preferable, since it can easily work offline and deal with private repos and mirrors.</div><div><br></div><div>Globally installed packages for erlang projects doesn't make sense to me, so a traditional package manager seems redundant - hopefully whatever tools emerge will be concerned with installing packages to a per-project deps directory. Like how rebar get-deps and npm install do. A robust API, well defined repo structure, and well maintained bunch of erlang code that uses it, would allow integration with rebar, rebar3, <a href="http://erlang.mk" target="_blank">erlang.mk</a>, hex, future tools, etc.</div><div><br></div><div><br>I tend to deploy releases by upgrading running systems (irccloud stuff), so I'm concerned with making sure my deps are well behaved in the .app and .appup department. The main reason i have to fork and patch erlang projects is to fix app and appup related mistakes or omissions, to make release upgrades work; at the moment, that means i change the git url to my fork - I'm not sure if there's a better way.<div><br><div>When I make a new release, and I'm feeling particularly masochistic, I try upgrading the versions of various third-party deps. Unfortunately, not many projects have valid .appups between versions. I end up forking and writing appups, or just not upgrading things. My fantasy package manager would have a command like:</div><div><br></div><div> $ epkgm "upgrade any of my deps as long as they have an appup file from my current version, so release upgrades will work fine"</div><div><br></div><div>...preferably with a flag for "don't do major version bumps that break the api". But unless the package repo comes with a giant integration-testing CI system, I don't think we can enforce or guarantee something like semver. I'd need to give this more thought, but for now I'm happy to continue trusting package authors to version things appropriately (and I'd read some changelogs/readmes..). I'd be content to review which new version of any dep to upgrade to once I run that command.</div><div><br></div><div>If I then go and fork a dep I'm using to add an appup file, it would be nice if it was easy to find by other people using that dep. This is kind of related to my ongoing struggle with figuring out which github fork is the "best" for any given erlang project. Perhaps a new package repo for erlang could address this be collecting some package usage statistics.</div><div><br></div><div><br></div><div>I'm aware this appup stuff is an unnecessary burden for people not concerned with release-upgrades. I certainly don't care about it when trying something new, or building something that could tolerate being restarted for upgrades. I don't want to feel pressured into writing and testing appups before publishing a useful new library. Per-package metadata is one way, but perhaps some sort of release-upgrade-friendly channel vs. main, like how apt does stable/unstable/testing - if you have to support hot-upgrading releases, stick to the appropriate channel.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div><div>RJ<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><div><br></div><div><br></div></div></font></span></div></div><div><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 31 December 2014 at 14:39, Palmer <span dir="ltr"><<a href="mailto:assistant.mechanic.palmer@gmail.com" target="_blank">assistant.mechanic.palmer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Joe Armstrong <erlang <at> <a href="http://gmail.com" target="_blank">gmail.com</a>> writes:<br>
><br>
> Interesting - I read the papers and was impressed - I downloaded NiX<br>
> on my MacBook and the first command in the tutorial I was following<br>
> failed.<br>
><br>
> Can anybody point me to a good tutorial other than the manual page<br>
> and various academic papers?<br>
<br>
</span>Hi Joe,<br>
<br>
The OS X version of Nix has been under development recently. You should try<br>
using the testing branch.<br>
<br>
Setup instructions here:<br>
<br>
<a href="https://nixos.org/wiki/Nix_on_OS_X" target="_blank">https://nixos.org/wiki/Nix_on_OS_X</a><br>
<span><font color="#888888"><br>
-Palmer<br>
</font></span><div><div><br>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div></div></div></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Mark Nijhof<br><div><div>t: <a href="https://twitter.com/MarkNijhof" target="_blank">@MarkNijhof</a><br>s: marknijhof</div></div><div><br></div></div></div>
</div>