<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    On 02/05/2012 21:12, Tristan Sloughter wrote:
    <blockquote
cite="mid:CAAQdjxe-yhGg0MZksBFGjf8ocmQOa8pCO+2G3Bf1iR+GxUvGeA@mail.gmail.com"
      type="cite">Yeah, the discussion between you and Eric seemed much
      larger of a goal and one that would require mass adoption.
      <div><br>
      </div>
    </blockquote>
    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.<br>
    <blockquote
cite="mid:CAAQdjxe-yhGg0MZksBFGjf8ocmQOa8pCO+2G3Bf1iR+GxUvGeA@mail.gmail.com"
      type="cite">
      <div>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.</div>
      <div><br>
      </div>
      <div>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.</div>
      <div><br>
      </div>
    </blockquote>
    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).<br>
    <br>
    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.<br>
    <blockquote
cite="mid:CAAQdjxe-yhGg0MZksBFGjf8ocmQOa8pCO+2G3Bf1iR+GxUvGeA@mail.gmail.com"
      type="cite">
      <div>Tristan<br>
        <div><br>
          <div class="gmail_quote">
            On Wed, May 2, 2012 at 3:03 PM, Tim Watson <span dir="ltr"><<a
                moz-do-not-send="true"
                href="mailto:watson.timothy@gmail.com" target="_blank">watson.timothy@gmail.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              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.<br>
              <br>
              I'm sure this area will continue to improve over time
              though, especially as new tools (hopefully) emerge.<br>
              <div>
                <div class="h5"><br>
                  On 2 May 2012, at 19:39, Ciprian Dorin Craciun <<a
                    moz-do-not-send="true"
                    href="mailto:ciprian.craciun@gmail.com">ciprian.craciun@gmail.com</a>>
                  wrote:<br>
                  <br>
                  >    (As no-one replied in 4 days, I'll add my
                  opinion...)<br>
                  ><br>
                  > On Sat, Apr 28, 2012 at 4:36 PM, Tristan
                  Sloughter<br>
                  > <<a moz-do-not-send="true"
                    href="mailto:tristan.sloughter@gmail.com">tristan.sloughter@gmail.com</a>>
                  wrote:<br>
                  >> I started with this problem as something to
                  simply discuss with the<br>
                  >> maintainers of certain build and package
                  management projects -- sinan and<br>
                  >> agner specifically. But it seems to be more
                  broad and cover how all of us<br>
                  >> who keep apps on github handle versioning and
                  dependencies.<br>
                  >><br>
                  >> The basic issue is app versions within .app
                  files on branches in github, the<br>
                  >> resultant directory from a agner install and
                  the discrepancies this causes.<br>
                  >><br>
                  >> [...]<br>
                  >><br>
                  >> Am I the only one going crazy with this?<br>
                  ><br>
                  >    Nop. I've been faced with this problem myself
                  a couple of times.<br>
                  > (I've chosen to ignore it.)<br>
                  ><br>
                  ><br>
                  >> Does anyone have<br>
                  >> suggestions/examples of what they do for
                  production projects on teams to<br>
                  >> ease these annoyances?<br>
                  ><br>
                  >    For example for my project I have one big Git
                  repository called<br>
                  > `myproject-repositories` (replace `myproject`
                  with what you need) with<br>
                  > submodules pointing to the dependencies.<br>
                  ><br>
                  >    Then inside my own project repositories I have
                  a symlink<br>
                  > `.repositories` poiting to the "current" snapshot
                  of dependencies.<br>
                  ><br>
                  >    I also don't use any of rebar, agner, etc.,
                  mainly because I've<br>
                  > hacked something on-top of the ninja build
                  system.<br>
                  ><br>
                  ><br>
                  >> I mostly just create my own packages and
                  repos of dependencies, or package<br>
                  >> third party deps with the project.<br>
                  ><br>
                  >    Yup. +1 :)<br>
                  ><br>
                  ><br>
                  >    P.S.: I hate Java from the bottom of my heart,
                  but boy-o-boy is<br>
                  > the Java tooling way better than that of
                  Erlang... I mean what Erlang<br>
                  > is missing is something similar to NodeJS's NPM,
                  or Java's Maven<br>
                  > (minus the XML baggage and all useless
                  complexities), or Python<br>
                  > setup-tools (with virtual environment), etc...<br>
                </div>
              </div>
              > _______________________________________________<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>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
  </body>
</html>