From mboxrd@z Thu Jan 1 00:00:00 1970 From: Amirouche Boubekki Subject: Re: guix is the guildhall that we always wanted! Date: Thu, 16 Mar 2017 20:26:52 +0100 Message-ID: <26e9ccc02b354bfb7e3dd80972fcc5b7@hypermove.net> References: <87zigl3wph.fsf@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cob3E-0000rI-8X for guix-devel@gnu.org; Thu, 16 Mar 2017 15:27:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cob3A-0003kz-W6 for guix-devel@gnu.org; Thu, 16 Mar 2017 15:27:08 -0400 In-Reply-To: <87zigl3wph.fsf@pobox.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Andy Wingo Cc: guix-devel@gnu.org, guile-user@gnu.org, guile-user 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