Re: Mechanism for helping in multi-channels configuration

[Christina O'Donnell <cdo@mutix.org>]

Hi Simon,

> The wishlist is: provide a machine-readable description on guix-science
> channel side in order to help in finding the good overlap between
> commits of different channels.
>
> It could be nice if instead of an hard error, “guix pull” could say:
> « the channel ’guix’ needs to be at least at commit 1234abc ».

I was just thinking about these kinds of errors. It would also happen 
between
channels when packages are split from a single file (eg. golang.scm to
golang-xyz.scm). Then channels immediately go out of sync as we're doing
continual releases. So, it wouldn't just be for time-machine. It's all a 
bit too
fragile for my liking. I assume we won't be to frequent versioned 
releases any
time soon..

A sketch of a solution might be:

  1. Have a script that scrapes all the define-public symbols in every 
file in
     every package.
  2. Have a script that determines the symbols needed by each file. (Macros
     make this more difficult, but.)
  3. Have both scripts have an incremental version that runs on diffs (for
     performance).
  4. Run this for every commit on every branch on every channel caching the
     result.
  5. Have a CI script keep this updated for new commits.
  6. Have a server track incompatibilities.

For example, a 'definition-reference' could look like,

(definition-reference (commit-range start-hash end-hash)
                       file-path
                       identifier)

(definition-reference (commit-range "44b340d..." "06dba3b...")
                       "gnu/packages/golang"
                       'go-github-com-rs-xid)

Commit ranges makes the size of entries tractable (since package 
probably aren't
getting moved / deleted / added very much).

Then use a hash table, (or trie or B+ Tree, or distributed hash table, 
etc) to
go from identifier to definition-reference.

You would probably would also want to know commit date so you could 
index on it.
That would let you find versions that supplied the identifier that are 
as close
as possible chronologically to a particular version of a different channel

Now this isn't perfect (in case anyone was getting that impression ;):
  - It won't have any idea about version incompatibilities.
  - It couldn't trace renamed variables.
  - And probably more.

Might be useful to additionally track package versions, but that might 
run into
resource issues.

I'm thinking a Guile daemon backed by SQLite.. What do you think?

Full disclosure: I've got nothing lined up for the summer yet, so I'm on the
prowl for GSoC projects :)

Kind regards,
  - Christina