[Melbourne-pm] The grass on the other side..

[Mathew Robertson]

>> 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.
>>     
>
> I understood that to be more a Maven (apt for Java) feature than a language
> feature, when dealing with this sort of thing.
>   
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).

Its description file use lots of magic to determine when it does 
stuff... I've given up on numerous occasions trying to understand it -> 
I found it far too complicated to get anything useful done with it.
>> How would that work in the Perl ecosystem?
>>     
>
> 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.
>
> [...]
>   
When running a maven project in developer mode, maven will automatically 
download project-dependent packages+versions, and stick them in ~/.maven.

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.
>> 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.
>>     
>
> *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.
>
> [...]
>
>   
>> But apparently this is acceptable behaviour elsewhere. I'm curious
>> though.. does it suffer from the instability issues, or does it Just Work?
>>     
>
> My comments are based on my practical experience, save the Maven-ish bits,
> where I only know a tiny bit.
>   
likewise...
>   
>> 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?
>>     
>
> Almost certainly not.
>   
As with all code, at some point you will fix bugs or add features which 
are incompatible -> its just far too hard to maintain API and/or ABI 
compatibility.

In my experience, Perl's "version" handling is pretty good compared to 
other programming environments, but I'm in agreement -> 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.

** 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?)

>> Or is there something inherent in Perl's community and/or release structure,
>> that causes the pain?
>>     
>
> 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.
>   
Indeed - the Java community gave up trying to make a projects' 
dependencies play nice -> each project will now almost always ship the 
dependencies as binary blobs within the tarball.

Mathew Robertson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/melbourne-pm/attachments/20091125/3f366eda/attachment.html>