[erlang-questions] Erlang package manager

[Mark Nijhof]

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.

-Mark



On Fri, Jan 2, 2015 at 12:26 PM, Richard Jones <rj@REDACTED> wrote:

> 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
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>


-- 
Mark Nijhof
t:   @MarkNijhof <https://twitter.com/MarkNijhof>
s:  marknijhof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150102/445bce4b/attachment.htm>