<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:87hbskwpbf.fsf@rimspace.net" type="cite">
  <blockquote type="cite">
    <pre wrap="">The thing that I found interesting was this choice for Lift to auto-update
your dependencies. I don't know how often it does it, I know it isn't every
time you subsequently run it.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I understood that to be more a Maven (apt for Java) feature than a language
feature, when dealing with this sort of thing.
  </pre>
</blockquote>
maven is not quite an "apt for java"... nobody *really* knows what it
is, as it does weird stuff all over the place.  Apparently the
developers think it is a project management tool, but is mostly used as
a replacement for "ant" (aka "make" for java).<br>
<br>
Its description file use lots of magic to determine when it does
stuff... I've given up on numerous occasions trying to understand it
-&gt; I found it far too complicated to get anything useful done with
it.<br>
<blockquote cite="mid:87hbskwpbf.fsf@rimspace.net" type="cite">
  <blockquote type="cite">
    <pre wrap="">How would that work in the Perl ecosystem?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Again, my understanding was that most projects listed their dependencies as
"random-library-1.1", and only version 1.1 would be installed, or suffice.

[...]
  </pre>
</blockquote>
When running a maven project in developer mode, maven will
automatically download project-dependent packages+versions, and stick
them in ~/.maven.<br>
<br>
When you create the projects' release-build, normally the build system
will package every dependency into a single jar/war/aar/mar/... file,
so that production code doesn't auto-update.<br>
<blockquote cite="mid:87hbskwpbf.fsf@rimspace.net" type="cite">
  <blockquote type="cite">
    <pre wrap="">I think we'd laugh at the concept.. It would be plagued by incompatible
updates hurting each other, or by one duff update screwing the rest, or by
circular dependencies getting stuck.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
*nod*  Usually, in Java, updating arbitrary JARs is prone to these issues,
because the habit of distributing packages with applications, and using
versioned dependencies, means that many third party libraries don't practice
ABI compatibility.

[...]

  </pre>
  <blockquote type="cite">
    <pre wrap="">But apparently this is acceptable behaviour elsewhere. I'm curious
though.. does it suffer from the instability issues, or does it Just Work?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
My comments are based on my practical experience, save the Maven-ish bits,
where I only know a tiny bit.
  </pre>
</blockquote>
likewise...<br>
<blockquote cite="mid:87hbskwpbf.fsf@rimspace.net" type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">If the Perl behaviour was changed to always-auto-update, would there be a
short period of pain, while we fixed stuff, but then a golden age of
reliability?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Almost certainly not.
  </pre>
</blockquote>
As with all code, at some point you will fix bugs or add features which
are incompatible -&gt; its just far too hard to maintain API and/or ABI
compatibility.<br>
<br>
In my experience, Perl's "version" handling is pretty good compared to
other programming environments, but I'm in agreement -&gt; there is no
way (currently **) that the Perl community could
auto-update version dependencies,  a given package may depend on
another packages' version-specific API/ABI.<br>
<br>
** If Perl's module support could be extended so that multiple module
versions could be installed, when combined with Perl's version
handling, it may be possible to do it... however, the Perl interpreter
would also need to support having two versions of the same module
loaded (aka each modules' symbols would also need version metadata - is
this already available?)<br>
<br>
<blockquote cite="mid:87hbskwpbf.fsf@rimspace.net" type="cite">
  <blockquote type="cite">
    <pre wrap="">Or is there something inherent in Perl's community and/or release structure,
that causes the pain?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Nope.  Conversely, the Java community is *not* better at this than we are:
part of the reason that the habit of shipping third party binary libraries
with your application came about was to address the issue of ABI
compatibility.
  </pre>
</blockquote>
Indeed - the Java community gave up trying to make a projects'
dependencies play nice -&gt; each project will now almost always ship
the dependencies as binary blobs within the tarball.<br>
<br>
Mathew Robertson<br>
</body>
</html>