Re: Adding stuff to the core distro (was Re: Infix syntax)

[Daniel Skarda]

> Two parties I'd like to keep in mind when making these decisions:
> 
>   - the packagers - we should consider what happens if I want to
>     package guile for debian and we've stuck guile-gtk, qt, kde,
>     gnome, etc. all in the main tree.  If I build and install with
>     everything, I can assure you there will be a *lot* of users who
>     will (legitimately) complain that I'm forcing them to install, say
>     X, gtk, qt, and gnome on their *non-X* system.  There are a
>     variety of ways we could handle this, but I think it's important
>     to keep in mind.
> 
>     (This has actually been a fairly major hassle to fix in the
>     current emacs21 wrt x and no-x, and I'm still not finished.)

  In my opinion, Guile _development_ should not copy the way how various
distributions split Guile into packages. 

  Last time I compiled Emacs myself, it was one big executable - either 
with or without X support (no modules possible). Guile has big advantage over
Emacs that it can be split into modules and these modules can be distributed
independently (with different dependencies). 

>   - the special cases -- we should consider what effect any
>     arrangement we discuss might have on the difficulty of using guile
>     in small environments.  i.e. the user (or distribution) who wants
>     to put guile on a firewall, ipaq, or mini-board.  If we only
>     support a make install of 20MB+, then we're not considering this
>     case, and IMO it's not very workable to just say "these people
>     need to pick out the bits they need themselves" -- if we don't
>     have some policies wrt to our "core", then we'll eventually end up
>     with all kinds of cross-dependencies between different modules.

  "What if".

  Your are afraid that if Guile was bloated, Guile would lose users who want
to use Guile in small environments. Notice that are not such users - otherwise
there would be demand for small guile or there would be such guile distribution
already. How can Guile lose users that it does not have?

  I am afraid that Guile has not many users. I am trying to find better
development model and how to attract more users. I am thinking: better
development -> more users (-> more developers ...). Also when more users are
familiar with Guile and use it for their daily work, it is more likely that
somebody choose Guile for his ipaq application...

  I think that there are many ways how to strip down Guile and decide what
should or should not be included. Until there is somebody who really needs such
Guile, we are not able to guess which way is right. It seems to me that you want
to invent a hammer, but you do not know yet what it will be good for.

>     As an example of a policy question -- if we added a perlre module,
>     would it be OK for the core code to use it?  How about srfi-1?,
>     etc.

Lynn Winebarger <address@hidden> writes:
> Keeping the trees separate is a proactive measure for preventing code incest.

 (I had to read this sentence few times before I fully understood it :-)

 srfi-1 is very good example - it is really large module and it sometimes makes
me thinking: "I want to use only function `every' (or fold-left) - why I have to
include so BIG list library?"
 
 Pros/cons:

   + srfi-1 is standard

   - it is so BIG

   + If I implement fold (every, any) every time I need it, again and again, 

      - I waste my time - it negates any benefits that come from standard 
libraries
 
      - I bloat code of my programs anyway (various `fold' implementation - here
        and there...)

      - when I copy buggy implementation of `fold', I also copy a bug. When I
        fix the bug, I also have to fix all copies of `fold'....

  If I do not bloat my program by using BIG srfi-1, I end up with zillions of
fold (every,and*..) implementations bloating every library. So, 
(use-module (srfi srfi-1)) or not to (use-module (srfi srfi-1))? That's
question. 

  What does it mean "keeping the trees separate is a proactive measure for
preventing code incest"? If it means that every guile developer has to reinvent
the wheel again and again (because of holy grail of small set of dependencies),
than it is bad measure.

  We should distinguish three different problems:

  Development process - I think that we should integrate here as much as
    possible. When I say "integrate", I do not mean "put everything in one big
    libguile.so or boot-9.scm", rather I mean "one development pot".

    Even though Neil announced his guile-debugger many times, it passed
    unnoticed by many developers (though many of them wrote in their TODO list -
    "I really have to look into guile-debugger..." :-) I bet that if somebody
    had merged guile-debugger sooner, it would have been already in wide use and
    possibly it would already have been enhanced with many new features.

  Release - when "one big pot" is not feasible, it seems that Guile has to be
    split into packages (just for release). I think that it is not wise to use
    "smallest dependencies" criteria, instead I would split packages "logically"
    - I would look for the ways people often use them. Guile-Gdk would depend on
    less packages than Guile-Gtk, but almost all people use them together. If
    somebody really, really wants to extract Gdk bindings out of Guile-gtk,
    he should invest some work. 

    If we want to think of all ways in which people may use Guile and a priori
    satisfy all possible demands on Guile, we are going to fail. Nothing is
    perfect from the beginning. We should be careful to not to close some doors
    (many interdependencies now -> hard to make stripped down version later),
    but such care should not paralyse and slow down development.

  Policies - As you already warned, we should consider what policies we keep
    so we do not close any door and make some further development impossible.

  Please, separate these three issues in your mind. Policies should only affect
the source code, they should not slow down development or make it harder.

  Guile is divided into packages according to distribution policies. Using
distribution (foreign) policies during Guile development sounds unnatural to
me. To divide Guile to several packages is the task of package maintainer.
  
0.