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

[Felix Gallo]

I think you can probably trust Loïc to do the right thing and never point
those tags at different commits.  So for that code, tag is probably fine.

Generally I find myself pointing at commits, though; not that much more
effort, and provides a solid invariant.

For code that absolutely has to work (manages $10B or more in assets under
management, runs MRI machines, etc.), I fork the project on github and
point my project at my fork.  That way even if the base repo dies or,
worse, suffers some kind of malevolent attack, the dependency is safe as
long as github itself is safe.  You can fork infinitely on github.

Over $500B assets under management, I run my own repo...

F.

On Wed, Mar 18, 2015 at 10:51 AM, Joe Armstrong <erlang@REDACTED> wrote:

> 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
> _______________________________________________
> 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/20150318/b4249be0/attachment.htm>