Ted Leung on the air
Ted Leung on the air: Open Source, Java, Python, and ...
Ted Leung on the air: Open Source, Java, Python, and ...
Wed, 08 Feb 2006
What is it about packaging?
[22:55] |
[computers] |
# |
TB |
F |
G |
9 Comments |
Packaging is just one of those things that has always bothered me. Search paths, library paths, incorrect dependencies. This stuff is just a pain in the neck. Recently I've been reading a bunch of posts about packaging. Ian Bicking wrote one about the use of Python's site-packages directory. Joe Gregorio wrote one about the evils of setuptools. Back when I was doing stuff in Java, there were any number of problems related incorrect classpaths, mismatched jars and so forth.
These problems are so bad that we have to build decently complicated programs (which then become their own problem) to manage the problem. There's Maven (hated by half the Java community, loved by the other half), the CPAN shell, Ruby's gems, Python's setuptools, and the plethora of package managers for Linux.
There does seem to be a common thread, though. Almost all of these systems/languages have their roots in Unix.
Good thing I still have my Unix Barf Bag...
[ Update: some people like setuptools -- I'm in this category myself ]
The main problem with packaging is that it's almost always an afterthought. It always seems like an annoying, unnecessary afterthought, but that's because the problem being solved is obscured.
An unpackaged program only works in one place. Half the program is in the source itself, and half of it lives in undocumented and implied interactions with the host system. The process of packaging is enumerating all of the interactions, making them explicit, classifying them, and writing programs to re-establish them.
In other words, when you are writing unpackaged software, you are programming your computer, but when you are writing packaged software, you are programming the computers of everyone who might ever use it. Put that way, I think packaging sounds reasonably easy given the tools we have today - only a few dozen hours of effort, to expand the usefulness of a program to five orders of magnitude more computers :).
Posted by Glyph Lefkowitz at Thu Feb 9 03:00:03 2006
An unpackaged program only works in one place. Half the program is in the source itself, and half of it lives in undocumented and implied interactions with the host system. The process of packaging is enumerating all of the interactions, making them explicit, classifying them, and writing programs to re-establish them.
In other words, when you are writing unpackaged software, you are programming your computer, but when you are writing packaged software, you are programming the computers of everyone who might ever use it. Put that way, I think packaging sounds reasonably easy given the tools we have today - only a few dozen hours of effort, to expand the usefulness of a program to five orders of magnitude more computers :).
Posted by Glyph Lefkowitz at Thu Feb 9 03:00:03 2006
Most of the times is not about packaging but the confusion between packaging and configuration that creates the problem.
Posted by antonio at Thu Feb 9 04:06:46 2006
Posted by antonio at Thu Feb 9 04:06:46 2006
Packaging is something that programmers rarely comprehend. It is the realm of sysadmins and it is done to make life more consistent and replicable. Most developers don't see the need - they know their code works in their environment so how hard could it be to setup. This is why a lot of packaging efforts are wonky.
Posted by seth vidal at Thu Feb 9 08:37:09 2006
Posted by seth vidal at Thu Feb 9 08:37:09 2006
I really hope that one day you have to look at the monstrosity that is MSI. Packaging on windows is virtually non-existant : applications all come with their own run-as-root install programs that barf crap all over the filesystem and registry. This is a really really odd area to pick on unix... its a darn sight better than the other guys.
Also, where do you really think all those Java people are programming things like Maven? Most Java is still programmed on windows, and unix is relegated to a deployment role.
Posted by rjwittams at Thu Feb 9 09:05:03 2006
Also, where do you really think all those Java people are programming things like Maven? Most Java is still programmed on windows, and unix is relegated to a deployment role.
Posted by rjwittams at Thu Feb 9 09:05:03 2006
rjwittams,
I didn't hold up Windows as an example of something that's better than Unix. Arguing that Unix is better than Windows is too easy. It's 2006 -- can't we do better than what we have now?
Posted by Ted Leung at Thu Feb 9 10:14:04 2006
I didn't hold up Windows as an example of something that's better than Unix. Arguing that Unix is better than Windows is too easy. It's 2006 -- can't we do better than what we have now?
Posted by Ted Leung at Thu Feb 9 10:14:04 2006
The biggest difficulty I see with packaging lies with the variability of systems on which it will run. Just trying to match dependencies on two Linux boxes using the same kernel but different distros can often (more like usually) lead to a serious headache.
Packaging only accounts for part of the issue - the rest lies with the OS: providing tools that "intelligently" install and configure compilers and libraries, etc. (think Gentoo Portage or BSD pkg_install which are not perfect, but better than the usual shotgun approach).
Until developers can trust that the OS is going to provide access to libraries in a consistent way, we are pretty well stuck with having to bumble our way along as best we can, and relying on ever-more complicated tools just to handle configuration and installation of software.
Posted by Sjan Evardsson at Thu Feb 9 16:41:05 2006
Packaging only accounts for part of the issue - the rest lies with the OS: providing tools that "intelligently" install and configure compilers and libraries, etc. (think Gentoo Portage or BSD pkg_install which are not perfect, but better than the usual shotgun approach).
Until developers can trust that the OS is going to provide access to libraries in a consistent way, we are pretty well stuck with having to bumble our way along as best we can, and relying on ever-more complicated tools just to handle configuration and installation of software.
Posted by Sjan Evardsson at Thu Feb 9 16:41:05 2006
I've spent a bit of time over the past few months making my Python works packageable for Debian. Whilst this would seem somewhat unnecessary (we have setup.py, right?), there are certain advantages with classic packaging systems: they support upgrading and uninstalling, they acknowledge other parts of the system (such as compilers, library dependencies, and so on), and they work well with the packaging tools that users are going to be using.
Because of these things, I install most of my own works from Debian packages now. As I recall mentioning on comp.lang.python once upon a time, Python packaging systems could learn a great deal from (and cooperate much better with) existing packaging and dependency management tools such as smartpm.
Posted by Paul Boddie at Fri Feb 10 03:02:48 2006
Because of these things, I install most of my own works from Debian packages now. As I recall mentioning on comp.lang.python once upon a time, Python packaging systems could learn a great deal from (and cooperate much better with) existing packaging and dependency management tools such as smartpm.
Posted by Paul Boddie at Fri Feb 10 03:02:48 2006
All of my Python packages make use of setuptools, an extension to Python’s built-in distutils package that’s supposed to make life easier for everyone. After a recent mucking-about with my Python install, I got to see what happens if you t...
Posted by Trackback from Oakwinter.com :: Code at Fri Feb 10 04:50:40 2006
Posted by Trackback from Oakwinter.com :: Code at Fri Feb 10 04:50:40 2006
I wonder how hard it would be to create egg2deb or egg2rpm... Dependencies would hurt for sure, but is there anything other than that?
Posted by Baczek at Sat Feb 11 07:34:13 2006
Posted by Baczek at Sat Feb 11 07:34:13 2006
You can subscribe to an RSS feed of the comments for this blog:
Add a comment here:
You can use some HTML tags in the comment text:
To insert a URI, just type it -- no need to write an anchor tag.
Allowable html tags are:
You can also use some Wiki style:
URI => [uri title]
<em> => _emphasized text_
<b> => *bold text*
Ordered list => consecutive lines starting spaces and an asterisk
Add a comment here:
You can use some HTML tags in the comment text:To insert a URI, just type it -- no need to write an anchor tag.
Allowable html tags are:
<a href>, <em>, <i>, <b>, <blockquote>, <br/>, <p>, <code>, <pre>, <cite>, <sub> and <sup>.You can also use some Wiki style:
URI => [uri title]
<em> => _emphasized text_
<b> => *bold text*
Ordered list => consecutive lines starting spaces and an asterisk
![[Valid RSS]](http://www.sauria.com/blog/images/valid-rss.png "Validate my RSS feed"){kind=small}
