On Sat, 6 Feb 2010 18:25:47 -0800 (PST)
Constantine Vetoshev <gepar...@gmail.com> wrote:
> On Feb 6, 1:06 pm, Peter Schuller <peter.schul...@infidyne.com> wrote:
> > But the practical issue
> > remains that if I want to write some software that I want sysadmins in
> > various situations to want to use effortlessly (in my case, a backup
> > tool), problems like these do get in the way of choosing Clojure.
> >
> > Maybe uberjars are the pragmatic approach after all. But then what
> > about GPL libraries and similar license hassles?
>
> I can't comment on the licensing problem, but could you expand on what
> exactly you don't like about packaging jars (as uberjars or separates)
> and distributing them as part of your application? If you distribute
> your app with precisely the jars you tested with, you don't have to
> worry about subtle incompatibilities sneaking in. Except for obviously
> bloated software (e.g., JBoss), Java jar files are relatively small.
> When you package for Debian, put the jars in /usr/share/my-awesome-app/
> jars, put in a dependency on sun-java-1.x, and provide a wrapper shell
> script to start the whole thing (your classpath just includes the
> stuff you provided). For the installing admin, your package is just an
> "aptitude install my-awesome-app" away, and it just pulls down a JVM
> dependency. Simple, and fairly lightweight.
It means that your software isn't playing well in the system. You
install a duplicate copy of everything - or nearly everything - you
require, basically creating a "weird parallel universe" just for your
application.
> I stopped using Python and Ruby and Perl partly because the packaging
> situation for all those languages is a horrible mess. For example, if
> you write a Ruby app, you are highly likely to run into trouble
> packaging it even for a recent distribution because your dependencies
> may not have been packaged or made available as rb-*.debs in the
> official repository. Or, rb-*.debs exist, but provide an incompatible
> version of the library you need. Ubuntu and Fedora may ship different
> versions of common gems, so you can't even code against an obvious
> lowest common denominator. (To make matters worse, "gem install",
> "easy_install", and "cpan -i" all create weird parallel universes of
> packages which may cause conflicts with system-provided packages.
> Python's virtualenv helps mitigate the problem to some extent.)
The first part isn't an issue with the python/ruby/perl packaging
software, it's an issue with the OS packaging systems providing
out-of-date or no versions of things you need. That's pretty much why
I've punted on Linux as a development environment - I couldn't find a
distribution that had up-to-date versions of the tools I wanted
available.
This second part also sounds like a problem with the OS packaging
system, not python, ruby, cpan, etc. FreeBSD solves these problems by
making the packaging system cpan/easy_install/etc. aware, so that when
you install an OS package, it goes through those systems, and when you
install something with those systems, the OS will notice them and let
them satisfy the dependency on things that need it. I suspect that
pkgsrc does the same, given how modular it is.
> C programs have it easier, because the overwhelming majority of
> commonly used libraries are packaged and available in recent
> distributions, and I have rarely had trouble with just writing against
> a slightly older version of a library. It's perfectly reasonable to
> dynamically link against libjpeg and make a note of a libjpeg
> dependency in the package descriptor file.
You've had better luck than I've had. Creating a truly static binary
using a modern GCC is nearly impossible, given that it wants to
dynamically link part of it's support code. I inevitably find that
critical shared libraries either aren't in the packaging system, or
are so far out of date the author lists them as "DO NOT USE". I
frequently find that even when the available tools are only a little
bit out of date, critical bug fixes or features aren't available in
that "slightly older library". Again, why I don't use Linux as a
development platform.
> In short, I think that the Java and Clojure way of packaging software
> make life much easier for programmers, package maintainers, and
> administrators, not harder. Making applications self-contained helps
> avoid dependency hell at packaging and deployment time, not to mention
> during development. It's a bit wasteful to have multiple copies of
> log4j or whatever floating around, but I'd rather waste a few
> gigabytes of disk space on duplicates than deal with system-wide
> classpaths.
I think of this as the "Windows" way of packaging, though calling it
the "proprietary" way may be more accurate. That solution works for
Python, Ruby, C - pretty much anything. You just bundle up every
dependency you can get a license for, cram it all into the application
directory, and distribute that along with a binary that arranges to
use all those things. It's essentually required if you're building a
distribution for an OS that has no packaging system, and you don't
want to put your users through "install X, Y, Z, W ...." just to use
your software. It also works if you want to distribute applications
to run on lots of different Linux distros without having to have
someone make the effort building a package for that distro - because
if you don't include everything, you'll inevitably run into a distro
that built things just different enough that your binary won't work on
their distro.
Maybe disks are big and cheap enough that bundling every third party
library with every application is an acceptable solution, but it still
makes me feel dirty. On the other hand, the only alternative I know of
is to get someone who actually knows the target packaging system to
add your application as a package, properly integrated into that
packaging systems environment.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
