Re: guix is the guildhall that we always wanted!
On Thu 16 Mar 2017 20:26, Amirouche Boubekki writes: >> 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 So I think we could re-use the "guild" command; see the original "guildhall" on how this is done. I dunno though, maybe that's not desireable. If it's not, maybe guildhall isn't the right name? I don't know. > 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 I think you would have to specify a git repo and it would have to be public, I think. (Should the web service mirror the repo? I don't know.) > Does it require login/password? Yes I think. Or at least email/token, where the service sends you the token to your email address. Dunno. We could use GPG but that is complicated too. >> 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. Yes :) >> 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? I mean that when a package is part of Guix it becomes part of Guix's continuous integration and build process, and Hydra will build it all the time, and it's a burden of sorts onto Guix. A value as well of course but a burden too. So what I am saying here is that we avoid that. >>- 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. "Guix pack" is orthogonal to this; it's just a nice way to deliver software. But for registering a package with the guildhall and its dependencies and arranging that you can just "git pull" the guildhall git repo which contains all the package.scm files in the guildhall -- that's what I mean. >> But! Who is going to build the guildhall v2.2? :-) > > idk ;) :) Andy
Re: guix is the guildhall that we always wanted!
On Thu 16 Mar 2017 23:01, Mark H Weaver writes: > If [Guix] starts encouraging a decentralized approach, that would > result in strong pressure on us to freeze our API, which includes even > such details as which module each package is exported from. This > would drastically reduce the freedom Guix has to evolve the way its > packages are specified. I get what you are saying. I think that if a future guildhall is decentralized but uses Guix it needs to minimize its burden on Guix. That could mean that the packages are actually specified in a different DSL with different stability characteristics -- for example that DSL could call specification->package under the hood for example, like Ludovic mentions. (I should mention that this idea of using Guix and especially all its errors are my own -- haven't talked to others about it yet!) Which module a package definition is in is a good example of something not to depend on. Basically I think Guix should be able to do what it wants to. The stability characteristics that Guix already has are sufficient for a Guildhall -- no additional maintenance burden intended and I hope no additional burden imposed. WDYT? Andy
Re: Guile 2.2.0 build fails at bootstrapping language/cps/types.go
Hello, 白い熊 skribis: > I'm trying to build the new GNU Guile 2.2.0 - my build fails > eventually with: > > make[2]: Leaving directory > '/home/shiroikume/compile/guile-2.2.0/libguile' > Making all in bootstrap > make[2]: Entering directory > '/home/shiroikume/compile/guile-2.2.0/bootstrap' > BOOTSTRAP GUILEC language/cps/types.go > /bin/bash: line 6: 27636 Floating point exception(core dumped) What architecture and operating system is this on? Thanks for your report! Ludo’.
Re: guix is the guildhall that we always wanted!
Hello! Andy Wingo skribis: > Crucially, this "guix pack" is really an SDK for Guile and Fibers. > Fibers is a library. You can now make an SDK for anything!!! I > mean, I know, that's a lot of exclamation marks, but check it: you can > develop locally, say using > > /opt/guile-fibers-1.0.0/bin/guile -L /path/to/my/code > > and it just works. If you package up your code, you can make a Guix > package out of it and make a "guix pack" out of that closure and > distribute it to your users: REGARDLESS OF WHAT OPERATING SYSTEM THEY > RUN, AND WITH FULL SOURCE REPRODUCIBILITY. It's huge. IT’S AWESOME ;-) > 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. > > So! My proposal for this new "guildhall" would be: > > 1. a web service > > 2. on which users registers projects > > 3. a project is a name + a git repository with a /package.scm file > > 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 >- without any manual checks >- in a form that you can just check out once and add to > GUIX_PACKAGE_PATH > > 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 > > 7. probably we need to steal many ideas from npm.org So are you suggesting that the new guildhall would provide Guix-generated packs for those who don’t use Guix, and otherwise regular Guix packages? > Open questions would be, what about other targets like macOS or Windows > or whatever? There I don't know. I suspect that if Guix becomes > popular enough, someone will make a thing whereby you can cross-compile > to macOS from GNU/Linux at least. I know you can do that already with > MinGW. As for native "guildhall" operation on these targets, I don't > know. But I think that is a cost that people will pay for in time. We could surely create cross-compiled packs for MinGW, though I suspect a number of packages do not support cross-compilation. Thanks for starting this thread! Ludo’.
Re: guix is the guildhall that we always wanted!
On Fri 17 Mar 2017 12:30, l...@gnu.org (Ludovic Courtès) writes: >> So! My proposal for this new "guildhall" would be: >> >> 1. a web service >> >> 2. on which users registers projects >> >> 3. a project is a name + a git repository with a /package.scm file >> >> 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 >>- without any manual checks >>- in a form that you can just check out once and add to >> GUIX_PACKAGE_PATH >> >> 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 >> >> 7. probably we need to steal many ideas from npm.org > > So are you suggesting that the new guildhall would provide > Guix-generated packs for those who don’t use Guix, and otherwise regular > Guix packages? No, I think the guildhall is simply another source of package definitions for Guix. Pack creation would be done by the user as needed -- if I want to ship packages A, B, and C, I can just do that. Some of those packages might be defined in Guix proper and some from guildhall. The interesting bit I think is simply being able to add to the set of guildhall packages in a decentralized way, to complement the set of packages in core Guix. I imagine the package flow over time would be from guildhall to core guix. Andy
Re: Guile 2.2.0 build fails at bootstrapping language/cps/types.go
On March 17, 2017 11:31:50 AM GMT+01:00, l...@gnu.org wrote: > >What architecture and operating system is this on? x86_64 Ubuntu GNU/Linux 4.4.0-67 -- 白い熊＠相撲道
Re: guix is the guildhall that we always wanted!
> From: l...@gnu.org (Ludovic Courtès) > Date: Fri, 17 Mar 2017 12:30:57 +0100 > Cc: guix-de...@gnu.org, guile-user@gnu.org > > > Open questions would be, what about other targets like macOS or Windows > > or whatever? There I don't know. I suspect that if Guix becomes > > popular enough, someone will make a thing whereby you can cross-compile > > to macOS from GNU/Linux at least. I know you can do that already with > > MinGW. As for native "guildhall" operation on these targets, I don't > > know. But I think that is a cost that people will pay for in time. > > We could surely create cross-compiled packs for MinGW, though I suspect > a number of packages do not support cross-compilation. The MinGW build doesn't support multithreading in Guile, so any such cross-compiled packages should be aware of that. Also, there are some Posix functionality not supported, like primitive-fork, so if Guix uses that, those parts won't work.
Re: guix is the guildhall that we always wanted!
Andy Wingo writes: > On Thu 16 Mar 2017 23:01, Mark H Weaver writes: > >> If [Guix] starts encouraging a decentralized approach, that would >> result in strong pressure on us to freeze our API, which includes even >> such details as which module each package is exported from. This >> would drastically reduce the freedom Guix has to evolve the way its >> packages are specified. > > I get what you are saying. I think that if a future guildhall is > decentralized but uses Guix it needs to minimize its burden on Guix. > That could mean that the packages are actually specified in a different > DSL with different stability characteristics -- for example that DSL > could call specification->package under the hood for example, like > Ludovic mentions. (I should mention that this idea of using Guix and > especially all its errors are my own -- haven't talked to others about > it yet!) > > Which module a package definition is in is a good example of something > not to depend on. This makes sense to me... if it really is true that our scheme'y Guildhall-style packages are so simple they're more data than code, maybe we could even restrict them to... just data. Just a list of what files are being provided, etc. That could easily be stored in some minimal database. I guess I'm saying +1.
Re: guix is the guildhall that we always wanted!
On Fri 17 Mar 2017 14:54, Christopher Allan Webber
writes:
> Andy Wingo writes:
>
>> On Thu 16 Mar 2017 23:01, Mark H Weaver writes:
>>
>>> If [Guix] starts encouraging a decentralized approach, that would
>>> result in strong pressure on us to freeze our API, which includes even
>>> such details as which module each package is exported from. This
>>> would drastically reduce the freedom Guix has to evolve the way its
>>> packages are specified.
>>
>> I get what you are saying. I think that if a future guildhall is
>> decentralized but uses Guix it needs to minimize its burden on Guix.
>> That could mean that the packages are actually specified in a different
>> DSL with different stability characteristics -- for example that DSL
>> could call specification->package under the hood for example, like
>> Ludovic mentions. (I should mention that this idea of using Guix and
>> especially all its errors are my own -- haven't talked to others about
>> it yet!)
>>
>> Which module a package definition is in is a good example of something
>> not to depend on.
>
> This makes sense to me... if it really is true that our scheme'y
> Guildhall-style packages are so simple they're more data than code,
> maybe we could even restrict them to... just data. Just a list of what
> files are being provided, etc. That could easily be stored in some
> minimal database.
Concretly I would propose something like this in a package.scm in the
git repo:
(use-modules (guildhall)) ; or whatever we call it
(import-guix-packages ((a "a")
(b "b@5.2")))
(define foo
(guildhall-package
(name "foo")
(inputs
`(("a" ,a)
("b" ,b)))
(git-url "https://github.com/foo/foo";)
(home-page "https://github.com/foo/foo";)
(synopsis "Foo is a thing")
(build-system simple-guile-build-system)
(description
"It's a thing")
(license license:expat)))
I guess you would not want to load this file from the web service as it
has arbitrary Scheme code inside it. I could see solutions where only
the end-user tool loads this file and exports data to the server, and
the server creates an appropriate "normal" package definition using just
the Guix API. It can write those definitions out to disk. It would
export a progressing git repository of Guix package definitions. As
Guix API changes, that server could re-render those package
descriptions. Of course that only works in some limited cases.
Otherwise you as a user could do this rendering process for packages you
are developing. Maybe it is a good thing to encourage nontrivial
packages to go upstream to Guix.
There's not a whole lot that is Guile-specific there of course. Maybe
this is just an exurb of Guix; I don't know. Probably "foo" might need
a local build story as well and this doesn't naturally solve that. More
thinking to do here!
Andy
Re: guix is the guildhall that we always wanted!
Hi Andy, It does look a lot like the channels we propose. Another thing to keep in mind is that it is possible to relocate guix binaries into any prefix so you do not actually need root privileges. It is something I am using for testing packages on HPC without root and I am going to make binaries available for the bioconda project. Pj.
Re: GNU Guile 2.2.0 released
Many thanks! Just did some benchmarks and it looks like there are decent performance improvements :) Regards Jan # Guile 2.0.11 make[1]: Entering directory '/home/jan/test/aiscm/bench' LD_LIBRARY_PATH=./.libs:/usr/local/lib GC_INITIAL_HEAP_SIZE=1G GC_USE_ENTIRE_HEAP=Y /usr/bin/guile bench.scm user system totalreal Guile GOOPS method dispatch0.50 0.00 0.50 ( 0.50) Guile make empty sequence 0.000160 0.00 0.000160 ( 0.000160) Guile allocate memory 0.000180 0.00 0.000180 ( 0.000180) Guile negate empty sequence0.001640 0.000120 0.001760 ( 0.001760) Guile make sequence0.000250 0.00 0.000250 ( 0.000260) Guile negate sequence 0.002370 0.000920 0.003290 ( 0.003300) C allocate memory 0.60 0.00 0.60 ( 0.60) C negate empty sequence0.30 0.00 0.30 ( 0.30) C negate sequence 0.000720 0.00 0.000720 ( 0.000720) make[1]: Leaving directory '/home/jan/test/aiscm/bench' # Guile 2.2.0 make[1]: Entering directory '/home/jan/test/aiscm/bench' LD_LIBRARY_PATH=./.libs:/usr/local/lib GC_INITIAL_HEAP_SIZE=1G GC_USE_ENTIRE_HEAP=Y /usr/local/bin/guile bench.scm user system totalreal Guile GOOPS method dispatch0.20 0.00 0.20 ( 0.20) Guile make empty sequence 0.40 0.00 0.40 ( 0.50) Guile allocate memory 0.000100 0.20 0.000120 ( 0.000110) Guile negate empty sequence0.000470 0.70 0.000540 ( 0.000550) Guile make sequence0.000110 0.10 0.000120 ( 0.000130) Guile negate sequence 0.001580 0.000910 0.002490 ( 0.002510) C allocate memory 0.30 0.00 0.30 ( 0.20) C negate empty sequence0.20 0.00 0.20 ( 0.20) C negate sequence 0.000690 0.10 0.000700 ( 0.000700) make[1]: Leaving directory '/home/jan/test/aiscm/bench'
Re: guix is the guildhall that we always wanted!
Andy Wingo writes: > On Thu 16 Mar 2017 20:26, Amirouche Boubekki writes: > >>> 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 > > So I think we could re-use the "guild" command; see the original > "guildhall" on how this is done. I dunno though, maybe that's not > desireable. If it's not, maybe guildhall isn't the right name? I don't > know. I’d think $ guild register # register with the guild What I long wanted to do: $ guild hall # show and change the defined package sources Adding guild sub-commands within guildhall is pretty easy. See https://github.com/ArneBab/guildhall/commit/3c9b78a91088cc66ecfc9ca7b62cf2a1d8f90781 I’d assume it’s similarly easy when starting fresh. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
