Re: features, modules and packages

[Alex Shinn]

>>>>> "Thi" == Thien-Thi Nguyen <address@hidden> writes:

    Alex> When it comes down to it, what the package manager is doing,
    Alex> and what the user is thinking in terms of, is specific
    Alex> versions of modules.

    Thi> ok, what version of guile is installed on the system now?  does
    Thi> it support `identity' or not?  can any published libguile api
    Thi> other than the source be trusted?  is the available source the
    Thi> source of the system's installed libguile (and ice-9 and
    Thi> whatever other crap makes up my environment)?  this user in
    Thi> particular loathes keeping track of these kinds of things.

Ah, but we need to keep track of something, and I'm simply saying that
for writing programs built on modules it's much easier to think in terms
of the modules themselves (and maybe the versions if you need something
recent/specific) than it is to keep a mental mapping of which modules
support which features.  Especially since later versions of the same
modules may have new features - it still all boils down to the module
version.

Your proposal suggested rather than depending on "guile-1.5.x" you
should really depend on certain features present in guile-1.5.x, and for
"core-language" features I fully agree.  For this reason feature-based
dependency should be available as one option for specifying dependencies
in packages.  However, for dependency on other external modules, I think
the only appropriate solution is to depend on the module itself,
optionally with a version number.

    Alex> The real feature list of a module is it's API, with all the
    Alex> procs it exports and all the behaviour therein.

    Thi> i'm glad to see people trusting others to uphold high
    Thi> engineering standards, although the dark side of the force,
    Thi> when your vendor changes things and doesn't document them
    Thi> properly, is powerful, too.  changes can include: reformatting,
    Thi> munging stuff that's not even used (by you), documentation
    Thi> changes with/without code changes, API upgrade, downgrade,
    Thi> sidegrade, etc.  trusting a version number (or any other name)
    Thi> requires trust for the entire chain of possible engineering
    Thi> best-practices deviance.

Well, yes, it is entirely a matter of trust, that's the whole point.
And, no, you're not supposed to expect others to uphold high engineering
standards.  That's why you can refer to exact versions, in case they
change something down the road.  It actually works out worse with casual
features, because people aren't going to define a new feature for every
little change.  Suppose you start writing a module frodo, based on
another module bilbo, and you release frodo depending on the feature
ring-bearer.  You later upgrade your installation of bilbo, and start
working more with it, using more procs that may or may not have been in
the earlier version.  When you make your next release of frodo, gumm
users may update it and the gumm script won't know to also install the
newer version of bilbo because the dependency hasn't changed.

Features are good for a process like the srfi's, but that's because they
*are* expected to uphold high engineering standards.  But it is a very
slow process done by committee.  If you want to build up a friendly
community of people sharing code, it has to be more informal.

Perhaps we are thinking of different things, and in that case I should
clarify where I'm coming from.  I didn't really qualify the gumm script
with an intent, I just said "hey, look at this" and that's not a good
way to get people interested in something.

On my Debian box I can say

  apt-get install some_program

and it will determine all the dependencies, download the packages, and
install them.  I very often hear this described as the single most
important technical advantage of Debian over other Linux distributions.

With Perl you can say

  perl -MCPAN -e "install Some::Module"

and it will again calculate the dependencies and download and install
everything you need.  Likewise, no matter what you think of Perl, this
is often touted as the single most important feature of the language.

So I would like to be able to say

  guile -c "(use-modules (gumm gumm)) (install (ttn ttn))"

and have it install the latest (ttn ttn) with all the dependencies.
This is really not a difficult goal (we're almost there), and could be a
huge boost to the Guile community.  But the next most important thing
after having this system available is having lots of modules, so we want
to make the process of creating modules and working out dependencies as
simple as possible.

    Thi> the proposed system allows for trust, anyway:

    Thi>    AC_GUILE_MODULE_REQUIRED(ttn spewutils)

    Thi> is this so onerous?

No, this is perfect.  And in the majority of cases is all you need.  But
every so often you end up with a scenario like the ring-bearer one.
Rather than requiring the other module author to factor out his changes
into some feature definition, it's much easier to just make your module
dependent on the new version.  So the distinction would work along the
lines of

  AC_GUILE_MODULE_REQUIRED(ttn spewutils >=version)

rather than

  AC_GUILE_MODULE_REQUIRED(ttn spewutils feature)

and more importantly this can be entirely automated.

But for core Scheme features we would still allow

  AC_GUILE_FEATURE_REQUIRED(regex)

and of course we would provide alternatives to autoconf for specifying
this information.

-- 
Alex