On 11/20/05, Pit Capitain <pit / capitain.de> wrote:
> IIUC, Tom suggested to split support for versioning and packaging.
> Separation of concerns is a well known method to decrease the
> complexity of systems. Can you tell us why you think that in this case
> it would be a bad idea?

Separation of concerns is all fine and good when you're dealing with
things that *can* be separated without increasing complexity. For
libraries, at least, I have come to the conclusion that you cannot
meaningfully separate packaging and versioning.

API versions are funny things. There should be language support for
selecting a particular API version. Given a promise that certain version
changes aren't supposed to affect the API, you can even select the
latest version within a range of versions (RubyGems does this with the
~> version selector).

If you don't have language support, then you're often left hoping that
the user has the correct version installed or doesn't upgrade. You can't
effectively lock your needs to a single version.

If you can lock, then you either need packaging support for version
resolution (e.g., to encourage the installation of the required package
at install-time) or you're again completely at the mercy of the user
*not* having installed the correct version and therefore being unable to
use your library or application at all.

You will still have problems when you need multiple versions of the same
API at the same time (e.g., sqlite_* and sqlite3_* in C/C++), but if
your library supports that sort of usage, that sort of thing should
probably be built into your namespacing techniques.

Package versions are often tightly tied to the API versions. If I need
version 1.2 of an API, I usually need version 1.2 of the package.

Packaging is not just the distribution format. It is also a way of
laying out files meaningfully after distribution. As has been discussed
on ruby-core, this does not just cover library layout, but *data*
layout, too. Two of my package currently have a data issue that RubyGems
allows me to solve semi-elegantly, but could be solved better in other
ways, I think. (This is not exclusively a RubyGems issue.)

Basically, we need core language support for versioning. Nothing that
Trans has proposed changes that. Indeed, he's merely shuffled the
directory structure in a completely nonsensical way that decreases the
ability of packagers to uninstall programs and libraries. He will
*still* have to meaningfully make require use versioning. Ultimately,
he's confusing the current less-than-optimal implementation of RubyGems
with what should be present when RubyGems is incorporated into the core
of Ruby.

I encourage Trans to release his code and encourage uptake. He won't get
it unless he has a packaging format or packaging format support, and I
don't see that happening, because he's compounded, not simplified the
problems.

-austin
--
Austin Ziegler * halostatue / gmail.com
               * Alternate: austin / halostatue.ca