Is there a way to publish an application locally (with or without rebar3)?

Questions / Help
,
1

What I’m looking for is to ship an application as a tarball or any other format and then “just install” it by name in a different machine. Ideally an entry in a rebar.config:

{deps,[
  {rebar, {file, "file:///tmp/myfile.tar.gz"}},

rebar3 tar comes close but the generated file is not something one immediately specifies to be installed (not that I’m aware of). I think I would have to untar the generated file then symlink it to _checkouts (Dependencies).

In terms of user experience something akin to:

python3 setup.py sdist --dist-dir ./output/sdist --formats=gztar

Then

pip3 install --upgrade file:///tmp/mylib-0.0.1.tar.gz

Naturally I’m open to ideas. Thanks in advance.

2 Likes
2

It sounds like what you’re looking for is a way to create a release.

Check out this section on releases and relx on rebar3.org

Likewise, checkout the releases section on adopting erlang for solid supplemental documentation.

Finally, here is a concrete albeit simple example (nothing more, nothing less) of an umbrella which is setup up with relx to be distributed as a release : GitHub - starbelly/feedhack: An example OTP application

I hope this helps and is on track with what you thoughts :slight_smile:

Edit:

It may you’re after a way to share your OTP application with other OTP applications on your machine. If that’s so, there’s no current equivleant to pip3 install --upgrade since that’s a package manager. There are of course solutions. When I think packages I think hex.pm . It may be that you’re just wanting this all for local dev though (even if on different machines)?

2 Likes
3

Hi @starbelly thanks for your reply.

I’ve read that docs but still I think it does not map to what I’m looking for.

Say I have a library lib_a, I would like to have both v0.0.1 and v1.1.0 locally available and easy to integrate with rebar3.

I was thinking: maybe creating a plugin for this is worth the effort? I’ve been learning erlang for a while now and I believe it would be a good challenge to do so.

I was thinking of adhering to the rebar3 tar idea, maybe saving those files to $HOME/.cache/rebar3/local (alongside $HOME/.cache/rebar3/hex) and have the plugin extract the relevant files and place them on _checkouts ? Does that look like a sound idea to implement what I’m looking for?

3 Likes
4

If my interpretation of what you are saying is correct then rebar3 tar is not what you want. It is for an OTP Release, Erlang -- Releases, this is not for packaging individual applications but for an entire runnable system.

I don’t have a Python analogy so will just say its like trying to use a Go program compiled as a binary as a library dependency.

What exactly are you trying to accomplish? Do you want to use an application as a dependency on another machine without putting it to git or hex? If it is local you can just use a symlink in _checkouts. If you need a different version in different projects then you’d need to make multiple copies and symlink to the appropriate one, but no need to create a tarball in the case you are working locally.

2 Likes
5

Hi, @tsloughter , thanks for your reply.

What exactly are you trying to accomplish?

I would like to do this, but with a file:

{deps,[
    {cowboy, {git, "git://github.com/ninenines/cowboy.git", {tag, "1.0.1"}}}

This is clean, effective and portable.

Do you want to use an application as a dependency on another machine without putting it to git or hex?

Yes, I want to have a library that I can copy between machines without having to put it on the internet.

If it is local you can just use a symlink in _checkouts.

Yes. This is clean and simple, but it is not handy if I want to have multiple versions. Unfortunately backwards incompatible changes happen, projects use old versions, etc.

If you need a different version in different projects then you’d need to make multiple copies and symlink to the appropriate one, but no need to create a tarball in the case you are working locally.

Yes but that implies having multiple copies of a project checked out somewhere. And also making sure I don’t change their HEAD. And in every project I would have to wrap that on custom make commands (or something to this extent).

Do you think writting a plugin to support

{deps,[
    {mylib, {file, "file:///path/to/somewhere/mylib_0.0.1.tar.gz"}}

Is a good idea? I’m kind of new to erlang so I might be missing something (that’s why I’m asking for help; I don’t want to put hours into this just to figure out that it does not fit nicely with the erlang ecosystem so to speak).

2 Likes
6

I meant more what problem are you trying to solve and not the solution you are trying to make work.

If you are working on multiple projects at the same time depending on separate versions then yea that can be a pain, I’d use like git worktree to setup multiple copies of the dep at the right commit and use _checkouts.

If you aren’t trying to make it fetch over the network I’m not sure why pointing to a directory isn’t enough?

But I’d also check for existing third party plugins that provide custom resources to fetch local or remote tarballs, it may exist.

2 Likes
7

Update: it is possible to build with local files by installing from git and referencing it by tag/ref. I think this fulfills my expectation of local development.

One can install from git and there’s even a git_subdir option to allow for a custom root place for your rebar3 application.

Example:

{deps,
    [
        {my_app,
            {git_subdir, "https://github.com/user01/my_repo", {ref, "aaaaaa0"},
                "subdir/other"}}
    ]}.

Caveat: my_app gets appended to subdir/other so that inside my_repo the rebar3.config file should reside on subdir/other/my_app. One can use the empty atom '' to “circumvent” that.

Naturally it is possible to use a file:///home/user/path/myapp path instead of https://github.com/user01/my_repo.

I have discussed a similar matter and got support here.

2 Likes
8

I guess GitHub - alinpopa/rebar3-localdep-plugin: Rebar3 plugin to enable local dependencies comes pretty close to what you are trying to do.
It does not handle tarballs and expects the application to be in rebar structure.
And of course GitHub - benoitc/rebar3_path_deps: A rebar plugin to specify path dependencies. doing pretty much the same.

2 Likes