[erlang-questions] Including other peoples code in my code in a future proof way

[Joe Armstrong]

On Tue, Mar 17, 2015 at 3:07 PM, Loïc Hoguin <essen@REDACTED> wrote:
> On 03/17/2015 02:53 PM, Joe Armstrong wrote:
>>
>> How do I include another application in my application?
>>
>> I've written a program that I want to distibute.
>> I'll make it available on github.
>>
>> The problem is that my program uses cowboy and a few other
>> things (which are also on github)
>>
>> I'd like my program to work "out of the box" - just type Make and off
>> you go.
>>
>> I'd also like my to work for a long time so if rebar and
>> cowboy change in the future I'd like my program to still build
>> correctly.
>>
>> Now what I could do is:
>>
>>      use rebar and a rebar.config file that point to cowboy etc.
>>
>> My rebar-config is like this
>>
>> {deps, [
>>     ...
>>    {cowboy, ".*", {git, "git://github.com/extend/cowboy.git", "master"}}
>> ]}.
>>
>> The problem with this is that
>>
>>     1) my version of rebar might not be the same as on the target machine
>>        where the makefile is run
>
>
> This is a problem erlang.mk solves. You include erlang.mk in your project
> therefore everyone has the same when they compile it.
>
> You still are at the whim of Make having an incompatible change that breaks
> something, but you also have that issue with rebar when a newer Erlang
> version breaks something in it. The chances of either happening are very
> slim though.
>
>>     2) The cowboy reference is to "the latest version" and not
>>        an immutable version that I know works
>>
>> So How should I fix this? Is the answer:
>>
>>      a) Include rebar in my distribution
>>        (I don't really like this, since I'd just like to have my code in
>>         my project archive)
>
>
> That's what I would advise you to do, though. Do note however that if your
> project is to be used as a dependency then it won't be your rebar that will
> be used but the user's (or the top-level project's) rebar.
>
> This is another issue erlang.mk solves as the dependency's Makefile is
> always used and not the top-level erlang.mk. The dependency can run a
> different erlang.mk or just a plain Makefile, or even a Makefile that calls
> the bundled rebar, it doesn't matter as long as there is a Makefile.
>
>>      b) Point to a absolute version of cowboy - but how do I do this?
>
>
> Simply put the tag or commit number instead of "master" in rebar.config, for
> example "1.0.1".
>
> Make sure to do this with all your dependencies, and check that the
> dependencies themselves do it.

I've run into another problem -
Right now I have a working program that I want to make sure works on
other peoples machines. So they need to get exactly the version I have

Right now I clone cowboy cowlib and ranch

   I then checkout   master from cowboy
                               tag 1.2.0 from cowlib
                               tag 1.0.0 from ranch

Everything works fine - great

If I publish this I assume the tagged versions 1.2.0 1.0.0 or cowlib and ranch
will be the same - but in the future master won't be the same

I then did a (inside cowboy)

  > git checkout master

and then

> git describe

fatal: No annotated tags can describe
'90ae31998e8d0887b9efe4b441136ac047708bb9'.

>From which I assume that I can use 90ae... etc as an immutable reference to
cowboy, and the 1.2.0 1.0.0 tags for cowlib and ranch

So now what I have to do is

clone cowboy and checkout 90ae31998e8d0887b9efe4b441136ac047708bb9'.
clone cowlib and checkout 1.2.0
clone ranch and checkout 1.0.0

Anybody who does this should get the same code as I have on my machine
is this correct?

Can I trust the tags? - do I have to converts these to shas with git describe
as well?

Cheers

/Joe





>
> I believe rebar3 has a way to lock dependencies into a specific commit for
> the projects that depend on another's "master".
>
>> Or c)
>>        Include all the source code of cowboy etc in my release
>
>
> This also works but will prove to be more time consuming when you need to
> update dependencies. However if you intend to just release the project and
> make little maintenance over it afterward (for example if it's a proof of
> concept or a prototype) then this might just be the way to go.
>
> --
> Loïc Hoguin
> http://ninenines.eu