guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: guix is the guildhall that we always wanted!


From: Amirouche Boubekki
Subject: Re: guix is the guildhall that we always wanted!
Date: Thu, 16 Mar 2017 20:26:52 +0100
User-agent: Roundcube Webmail/1.1.2

Héllo wingo!

On 2017-03-16 19:25, Andy Wingo wrote:
Hi all!


[...]

But it turns out that we can use the same strategy to distribute
reproducible binaries for any package that Guix includes.  Notably, if
you run:

  guix pack -S /opt/guile-fibers-1.0.0=/ guile-next guile-fibers
glibc-utf8-locales

Then what you get is a tarball that has Guile, Fibers, and everything
they depend on. It's safe to extract in / because it only adds files to
/gnu/store, and then it adds a symlink for /opt/guile-fibers-1.0.0.


cf. http://git.savannah.gnu.org/cgit/guix.git/tree/doc/guix.texi#n2392


So:

  * local development using packaged libraries: check.
* distribution of your work to people without $package-manager: check.
  * easy addition of your code to a common NPM-like registry: ?

For this last bit, we have two options.  One is to add your package to
Guix.  It's relatively easy; here's what I added for Fibers:

    (define-public guile-fibers
      (package
        (name "guile-fibers")
        (version "1.0.0")
        (source (origin
                  (method url-fetch)
(uri (string-append "https://wingolog.org/pub/fibers/fibers-";
                                      version ".tar.gz"))
                  (sha256
                   (base32
"0vjkg72ghgdgphzbjz9ig8al8271rq8974viknb2r1rg4lz92ld0"))))
        (build-system gnu-build-system)
        (native-inputs
         `(("texinfo" ,texinfo)
           ("pkg-config" ,pkg-config)))
        (inputs
         `(("guile" ,guile-next)))
        (synopsis "Lightweight concurrency facility for Guile")
        (description
"Fibers is a Guile library that implements a a lightweight concurrency
    facility, inspired by systems like Concurrent ML, Go, and Erlang.
A fiber is
like a \"goroutine\" from the Go language: a lightweight thread-like
    abstraction.  Systems built with Fibers can scale up to millions
of concurrent
    fibers, tens of thousands of concurrent socket connections, and
many parallel
cores. The Fibers library also provides Concurrent ML-like channels for
    communication between fibers.

Note that Fibers makes use of some Guile 2.1/2.2-specific features and
    is not available for Guile 2.0.")
        (home-page "https://github.com/wingo/fibers";)
        (license license:lgpl3+)))

OK, so this uses gnu-build-system, which requires a tarball; we need to
extend this to have a "guile-build-system" for modules that are just
Scheme, in which we just "guild compile" everything.  That way you can
have a repo on gitlab or whatever and you just specify the URL and the
revision and you are done. I don't know if we can get around specifying the sha256 when we specify the git revision; probably not a good idea in
light of the SHA1 breakage.  Anyway, that's a thing.

But while getting your package into guix is easier than you think, it's
not automatic.  I think there's room for a middle ground that's a bit
more decentralized than Guix, but more centralized than people using
GUIX_PACKAGE_PATH to add random directories of Guix package files.

Ok, I like the idea!


So!  My proposal for this new "guildhall" would be:

    1. a web service


What would be the cli interface associated with that web service?
Some thing like the following will do:

  $ guildhall register

    Register a package against the guildhall repository.
    You must have a package.scm in the current working
    directory that follows package specification of guix.
    http://link/to/guix/doc/that/I/dont/know

Does it require login/password?

That is all I can think of.

    2. on which users registers projects

    3. a project is a name + a git repository with a /package.scm file

We can have that using guile-git: current commit + remote origin.

4. the package.scm contains Guix package definitions for that project

    5. the web service administers a git repository collecting those
       packages
       - without any hydra.gnu.org overhead

What do you mean, by no hydra.gnu.org overhead? Where are
done the 'guix pack' command?

       - without any manual checks
- in a form that you can just check out once and add to GUIX_PACKAGE_PATH


Ok, the 'guix pack' can be done by the maintainer and
'guix register' does upload the lz file to guildhall
website.

    6. adding a new tag to a project's git repo of the form vX makes a
       release X and updates the guildhall package
       - it could be the web service has to poll git repos
       - or maybe you have to invoke some command to update guildhall

It's painful to have to "watch" git repositories, except if the git
repository is a remote of the develloper's git. Basically it requires
a manual intervention from the maintainer. Otherwise, guildhall website
need to pull regularly all git repositories.

    7. probably we need to steal many ideas from npm.org

I think about their dependency resolution algorithm. I think
civodul should chime in.


You might ask, why is this better than the current guildhall?  It does
exist after all.  I respond in the following way:


[...]


But!  Who is going to build the guildhall v2.2? :-)


idk ;)

I have also a question, for guix community:

What do you think of guix web, how one can improve it.
The idea I have behind that question, is that maybe we
should target to create a web ui for guix to improve
guile experience.


Amirouche ~ amz3 ~ http://hyperdev.fr



reply via email to

[Prev in Thread] Current Thread [Next in Thread]