[erlang-questions] Erlang package manager

[Richard Jones]

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 :)

Two main concerns from me: the nature of the repo/api/tools, and appup
related stuff.


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).
With any luck, this will mostly be just a bunch of files on disk in a
special directory structure.
Then expose an HTTP search interface that indexes the metadata.
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)
Then build tools that use the aforementioned HTTP API.
Pushing a new version of a package I author should make it publicly visible
without undue delay.

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.

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, erlang.mk, hex, future
tools, etc.


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.

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:

 $ epkgm "upgrade any of my deps as long as they have an appup file from my
current version, so release upgrades will work fine"

...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.

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.


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.


RJ










On 31 December 2014 at 14:39, Palmer <assistant.mechanic.palmer@REDACTED>
wrote:

> Joe Armstrong <erlang <at> gmail.com> writes:
> >
> > Interesting - I read the papers and was impressed - I downloaded NiX
> > on my MacBook  and the first command in the tutorial I was following
> > failed.
> >
> > Can anybody point me to a good tutorial other than the manual page
> > and various academic papers?
>
> Hi Joe,
>
> The OS X version of Nix has been under development recently.  You should
> try
> using the testing branch.
>
> Setup instructions here:
>
> https://nixos.org/wiki/Nix_on_OS_X
>
> -Palmer
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150102/50a4760b/attachment.htm>