[erlang-questions] Building, Packaging and Installing

Tim Watson <>
Thu May 3 02:06:45 CEST 2012


On 02/05/2012 21:12, Tristan Sloughter wrote:
> Yeah, the discussion between you and Eric seemed much larger of a goal 
> and one that would require mass adoption.
>
This is why we want to introduce 3rd party signing - so you can build + 
upload stuff you depend on that isn't necessarily being published by the 
original author(s). Of course our hope is that if lots of people want to 
use riak/lager/etc and decide to self-sign them so they can be used as 
dependencies, then the companies/teams behind those projects will be 
encouraged to join in.
> It was just more than I've been looking for. I can get packages 
> installed pretty easily, and if people tagged versions (and the 
> version of the app was the same as the name of the tag) I would have 
> almost no problems.
>
> So while what has been discussed on the Erlware list is great, I think 
> even just simple changes with no new tools could make a large difference.
>
Sure that seems fair enough. The issue of tagging is absolutely vital 
and I find it shocking that people aren't maintaining versions of things 
that intended for general use. I guess that's because I've spend enough 
time in a 'corporate' environment to become indoctrinated about such 
things, but generally I think it is The Right Thing To Do (TM).

The fact that people are maintaining custom forks of projects in order 
to be able to rely on them such seems totally wrong to me - a misuse in 
that forking should be about introducing your own changes (whether they 
end up going back upstream or not), but not about having to impose some 
kind of artificial snapshot on external dependencies.
> Tristan
>
> On Wed, May 2, 2012 at 3:03 PM, Tim Watson < 
> <mailto:>> wrote:
>
>     Eric Merit and I have had some lengthy discussions about this on
>     the Erlware mailing list and have some ideas that I think are
>     pretty solid. The thing is though, you don't just need tools - you
>     also need people to package their stuff up using the tools.
>
>     I'm sure this area will continue to improve over time though,
>     especially as new tools (hopefully) emerge.
>
>     On 2 May 2012, at 19:39, Ciprian Dorin Craciun
>     < <mailto:>> wrote:
>
>     >    (As no-one replied in 4 days, I'll add my opinion...)
>     >
>     > On Sat, Apr 28, 2012 at 4:36 PM, Tristan Sloughter
>     > <
>     <mailto:>> wrote:
>     >> I started with this problem as something to simply discuss with the
>     >> maintainers of certain build and package management projects --
>     sinan and
>     >> agner specifically. But it seems to be more broad and cover how
>     all of us
>     >> who keep apps on github handle versioning and dependencies.
>     >>
>     >> The basic issue is app versions within .app files on branches
>     in github, the
>     >> resultant directory from a agner install and the discrepancies
>     this causes.
>     >>
>     >> [...]
>     >>
>     >> Am I the only one going crazy with this?
>     >
>     >    Nop. I've been faced with this problem myself a couple of times.
>     > (I've chosen to ignore it.)
>     >
>     >
>     >> Does anyone have
>     >> suggestions/examples of what they do for production projects on
>     teams to
>     >> ease these annoyances?
>     >
>     >    For example for my project I have one big Git repository called
>     > `myproject-repositories` (replace `myproject` with what you
>     need) with
>     > submodules pointing to the dependencies.
>     >
>     >    Then inside my own project repositories I have a symlink
>     > `.repositories` poiting to the "current" snapshot of dependencies.
>     >
>     >    I also don't use any of rebar, agner, etc., mainly because I've
>     > hacked something on-top of the ninja build system.
>     >
>     >
>     >> I mostly just create my own packages and repos of dependencies,
>     or package
>     >> third party deps with the project.
>     >
>     >    Yup. +1 :)
>     >
>     >
>     >    P.S.: I hate Java from the bottom of my heart, but boy-o-boy is
>     > the Java tooling way better than that of Erlang... I mean what
>     Erlang
>     > is missing is something similar to NodeJS's NPM, or Java's Maven
>     > (minus the XML baggage and all useless complexities), or Python
>     > setup-tools (with virtual environment), etc...
>     > _______________________________________________
>     > erlang-questions mailing list
>     >  <mailto:>
>     > http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120503/1a03fcfd/attachment.html>


More information about the erlang-questions mailing list