<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 04/12/2014 01:41 AM, Benoit Chesneau
wrote:<br>
</div>
<blockquote
cite="mid:CAJNb-9qqFYCejs=j5fHE5x5G93URebfxorm-ZvmH4-mVPAD9oA@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html;
charset=ISO-8859-1">
<div dir="ltr">I tend to think like Fred. Between `apps/*` and
having 1 repo per app, I think it all depends the way your are
coding how how independent the apps are. Also depends how big
you are.
<div><br>
</div>
<div>I tend to use the apps/ structure when I need to have
different supervision strategy / apps but apps are not useful
by themselves. Or at least at this stage not enough isolated
to be used by themselves. Another reason for that is that it
make sometimes really difficult to test a *product* update
that goes over different apps, if they are isolated:</div>
<div><br>
</div>
<div>- you have to make sure to use the correct branch / apps</div>
<div>- you need to dl/link each apps</div>
<div>- you need to communicate to other what you're doing,
freezing some branches, etc.. </div>
<div><br>
</div>
<div>All of this requires a mechanic, that - if manageable -
takes times. (Changing he makefile to point to the right
branch, communicate overseas, sync the source repo, updating
the release to tell we are testing such feature...) and need
to be done very carefully once you have more than one
developer working on your product. I'm thinking that most of
the time when your product needs to use self-dependent apps
it's more solid to take a cathedral logic: keeping these apps
in one place and update them. (the apps/* folder similar to
the /usr and / folder on bsd systems). I am only speaking
about core applications - the one you invent/write -. Imo you
only need to split them as independent applications, when you
think that their code could be used independently (and want to
support it as a standalone app) or habe become optional in
your core application. </div>
<div><br>
</div>
<div>SInce your applications may use applications coming from
external, you still need a way to handle external depencies
though. And then we are back to my question ;)</div>
<div><br>
</div>
<div>I originally tested the cloudi approach, but I wonder how
do you support bugs and features request? What happen if
someone post you a patch on the Cloudi repository instead of
the standalone apps? Can really cloudi works only with its
core? I mean is the core like riak_core be usable by itself ?
(don't see any offense in these questions, I just don't know).</div>
</div>
</blockquote>
With the (main) CloudI repository at
<a class="moz-txt-link-freetext" href="https://github.com/CloudI/CloudI">https://github.com/CloudI/CloudI</a> all the dependencies are contained
within the repository (with a README that describes where the code
has come from with details, commit, authors, etc.) for the sake of
having a stable platform. Also, since CloudI wants to support
private cloud installations, it wants to have only a single
installable source which is transparent. The other CloudI
repository <a class="moz-txt-link-freetext" href="https://github.com/CloudI/cloudi_core">https://github.com/CloudI/cloudi_core</a> and the associated
<a class="moz-txt-link-freetext" href="https://github.com/CloudI/cloudi_service_*">https://github.com/CloudI/cloudi_service_*</a> repositories are relying
on rebar deps for their dependencies. Both approaches work, but the
rebar deps method of doing things can be prone to problems if tags
are not being used or if tags are changed for a dependency, or even
if a dependency history is rewritten.<br>
<br>
Having all the dependencies in the main repo requires tracking the
dependencies for changes manually, which is more time consuming but
helps protect the stability of the main project, despite the service
isolation (present in CloudI) that almost all the dependencies
utilize. So, this choice really depends on your stability
requirements and your testing for verification of new dependencies,
it all takes time, and the goal is to avoid failures in the source
code.<br>
<br>
If you do go the rebar deps route, it generally is best if you don't
checkin a rebar binary that lacks transparency (into your source
code repo, this has been a problem in the past) and if you use tags
for your external dependencies to lock down the potential problems
partially.<br>
<br>
<blockquote
cite="mid:CAJNb-9qqFYCejs=j5fHE5x5G93URebfxorm-ZvmH4-mVPAD9oA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>I also tested <a moz-do-not-send="true"
href="http://erlang.mk">erlang.mk</a>, + <a
moz-do-not-send="true" href="http://erl.mk">erl.mk</a> and
was aware about the deps passed as variable in the makefile,
but I didn't test it yet how it works with C binding. For
example I wonder how Garrett does with erlang-czmq to embed it
in another application with only the makefile. With rebar it's
quite easy, but with <a moz-do-not-send="true"
href="http://erlang.mk">erlang.mk</a> how does it works? (in
the case you have have 1 app depending from erlang-czmq and
building from it).</div>
<div><br>
</div>
<div><br>
</div>
<div>- benoit</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Apr 10, 2014 at 8:22 PM, Fred
Hebert <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>></span>
wrote:<br>
<blockquote class="gmail_quote">That's all fine by me too. As
I said, the apps/* layout is a layout I'd<br>
love to see get better support overall (I am mostly using
rebar, which<br>
does a lot of things halfway for that pattern, and relx,
which does it<br>
right).<br>
<br>
I'm in no position to tell tool builders what to do or how
to write<br>
their code -- I'm free to go around and fix it myself. If <a
moz-do-not-send="true" href="http://erlang.mk"
target="_blank">erlang.mk</a><br>
allows to override behavior (you did mention using a
top-level makefile<br>
to make things work), that's usually good enough and will
let people fix<br>
things the way they need it.<br>
<br>
Rebar makes it more complex because of how it builds its
list of path<br>
for transient deps (it needs to go down the directories
recursively, as<br>
with a 'compile' command or by specifying -r) -- which often
conflicts<br>
with running commands within a single directory (apps/ but
not deps/).<br>
This is what requires, for CT, calling 'rebar ct -r
skip_deps=true',<br>
which is far from obvious.<br>
<br>
But I felt like I should defend the directory structure I
feel makes the<br>
more sense for release-building, and therefore that I would
like to see<br>
love given for from tool builders :)<br>
<br>
Regards,<br>
Fred.<br>
<div class="im HOEnZb"><br>
On 04/10, Loïc Hoguin wrote:<br>
</div>
<div class="HOEnZb">
<div class="h5">> Another clarification.<br>
><br>
> On 04/10/2014 08:10 PM, Loïc Hoguin wrote:<br>
> >Just want to make sure one thing is clear.<br>
> ><br>
> >On 04/10/2014 07:52 PM, Fred Hebert wrote:<br>
> >>If you end up having to pay that price
purely because the build tool you<br>
> >>settled for was opinionated about whether
the apps in the apps/ or lib/<br>
> >>directory need to be checked out from other
repositories or if they can<br>
> >>be in there already, fix that build tool of
yours, because it's<br>
> >>clearly making decisions it should not be
making.<br>
> >><br>
> >>What's more important is that a tool that
supports both the apps/* and<br>
> >>the OTP app model can be able to also
support *both* of these workflows<br>
> >>(using deps or not to build the release),
depending on which is<br>
> >>appropriate for your project, team, and/or
community.<br>
> >><br>
> >>Denying people a way to organize their own
workflow because of your<br>
> >>personal opinion when the end result for
the files on disk is the exact<br>
> >>same (someone just disagrees about how they
ended up there), to me,<br>
> >>tells me that maybe your tool is a bit too
opinionated and may need to<br>
> >>take a step back.<br>
> ><br>
> >With regards to <a moz-do-not-send="true"
href="http://erlang.mk" target="_blank">erlang.mk</a>,
there's nothing to fix. There's nothing it<br>
> >does that prevent you from using the apps/*
layout. There's nothing in<br>
> >it that makes it all happen for you either,
because that's simply not<br>
> >the goal of the tool. But it can still fit very
easily in an apps/*<br>
> >layout, as demonstrated by the gist previously
posted. IRCCloud is one<br>
> >such big project that uses both <a
moz-do-not-send="true" href="http://erlang.mk"
target="_blank">erlang.mk</a> and an apps/* layout,
all<br>
> >without any problems AFAIK.<br>
> ><br>
> ><a moz-do-not-send="true"
href="http://erlang.mk" target="_blank">erlang.mk</a>
will always focus on one OTP application because that's
what<br>
> >it's designed to do well. Making it work on two
different scopes just<br>
> >makes everything harder, and then you end up
with nonsense like "rebar<br>
> >ct compile -r skip_deps=true" (quoting you) to
make it do what you want.<br>
> >I do not want that. On the other hand I want to
give greater power to<br>
><br>
> "I do not want that" refers to supporting the two
scopes in <a moz-do-not-send="true"
href="http://erlang.mk" target="_blank">erlang.mk</a><br>
> itself. It is of course very easy to have two
different scopes that do<br>
> exactly what you want by simply having one Makefile
at the top-level and one<br>
> Makefile for each application. There's nothing
preventing you to achieve<br>
> that in a clean manner.<br>
><br>
> I will not provide a .mk file for the apps/* layout
because I do not use it<br>
> and have no idea what it should do, but I probably
would accept a community<br>
> supported "apps/* layout" file in the repository.
As long as it's in a<br>
> contrib/ directory or something of course.<br>
><br>
> >the user to override or complement the default
behavior, and that<br>
> >alongside Windows support is most of the work
that remains to be done<br>
> >for <a moz-do-not-send="true"
href="http://erlang.mk" target="_blank">erlang.mk</a>
1.0. (Not that you can't change its behavior already
-it's<br>
> >a text file after all!- but I want to make it
even simpler.)<br>
> ><br>
> >tl;dr Do one thing and do it well; do it right
by default but allow<br>
> >overriding its behavior easily.<br>
><br>
> --<br>
> Loïc Hoguin<br>
> <a moz-do-not-send="true"
href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a moz-do-not-send="true"
href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a moz-do-not-send="true"
href="http://erlang.org/mailman/listinfo/erlang-questions"
target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
erlang-questions mailing list
<a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a>
</pre>
</blockquote>
<br>
</body>
</html>