Re: How did you handle making a GNU/Linux distribution?
Philip McGrath writes: > Hi Sage, > > On 8/22/21 5:53 PM, Sage Gerard wrote: >> Thanks for the detailed answer! >> It seems wise to adapt GNU Mes towards Racket or Chez Scheme instead >> of >> Guile to bring GNU's benefits to more Scheme and Racket programmers. Has >> someone already tried something like that? > > I haven't tried Xiden yet, and I haven't done any concrete work toward > this (I have been working on managing Racket packages with Guix), but > Christine Lemmer-Webber had floated the idea at some point of trying > to integrate Racket and Guile. > > IIRC, I think what she's had in mind was trying to make a Guile > backend for Racket along the lines of the Chez Scheme backend (or the > BC backend, or experimental backends like Pycket). Yes that's what I had in mind :) > As I said, I haven't actually tried any of this, but, as I've thought > about what might be involved, there are two things that have struck me > as downsides: > > 1. Flatt et al. say in "Rebuilding Racket on Chez Scheme (Experience > Report)" (§6, p. 13) that, "If our task were to compile Racket to an > existing target, then we would not have achieved such a high degree > of compatibility. … we have taken the liberty of modifying Chez > Scheme to make it an easier target for Racket." > > https://www.cs.utah.edu/plt/publications/icfp19-fddkmstz.pdf > > Presumably a Racket-on-Guile project would face the same trade-off, > where modifications to Guild, if Racket CS is a guide, could require > hard work over many years, and lesser compatibility would make the > result less useful. At one point when I spoke to Matthew, he was very optimistic that the work on porting on top of Chez would open Racket to running on top of many other backends. But yes... since there have been so many "custom" modifications to Chez, it's easier to be skeptical about that these days... > 2. As you probably know, Racket programs can't generally use > Chez Scheme implemented libraries, because Chez Scheme effectively > is the "unsafe" layer of the Racket VM. For example, not all Racket > procedures are Chez Scheme procedures, and Racket's continuations > wrap Chez Scheme's to implement delimited and composable control, > threads, parameters, full continuation marks, etc. > > For Racket CS, this isn't a great loss (there aren't so many > Chez-specific libraries, and portable libraries can run in Racket's > R6RS language), but, for a hypothetical Racket-on-Guile, > bidirectional interoperability would be a big attraction: imagine > Guix, Shepherd, Mcron, syntax/parse, racket/contract, and more all > working together. > > If I were going to work on this, I'd start by looking at having Racket > and Guile coexist as siblings with interoperability through their FFIs > level. Even better, eventually you could compile Guile to Racket > linklets, so the two could coexist in the same primitive module > system. There would probably always need to be something along the > lines of require/typed to interoperate between the languages, since > Guile has mutable pairs and an unusual approach to falsehood and > nullity to let Scheme's #f and '() coexist with Emacs List's nil. (See > https://www.gnu.org/software/guile/manual/html_node/Nil.html). > I'm at the point where users are requesting a GNU/Linux distribution for Xiden, such that Racket is the primary language for day-to-day operation. I'm ignorant of the scope of work, and am unsure if I can do it alone. > > To me, at least, the scope of the work in creating a new GNU/Linux > distribution seems daunting. My hope would be that bringing Racket and > Guile closer together would let most if not all of the effort be shared. > > Hope some of this is useful, and best of luck! > > -Philip
Re: Named environments
Ryan Prior writes:
> Hey Guix.
>
> I've been thinking lately it would be convenient to create certain uniquely
> named execution environments on my machine. For example, I might have one
> set up with dependencies for my Python webapp & environment variables set to
> autoconnect to a Postgres server. I might have another that's got test
> dependencies and is containerized, such that it can only access the network
> & not the rest of my filesystem. Suppose I name these two "webapp" and
> "test" respectively.
>
> I picture running eg `guix env @webapp -- uvicorn main:app` to start my
> server, then `guix env @test -- pytest` to run my tests.
>
> I might write a wrapper in some scripting language that sets up this kind of
> system. Would anybody else be interested in using such a thing? Would it
> make sense to integrate this capability into Guix itself?
>
>Ryan
I like this idea! (And adding a built-in alias from "environment" to "env"
might be worth it, too.)
I actually use an ad-hoc version of this in my ~/.bashrc, using aliases. For
example,
alias geg='guix environment guix --pure --ad-hoc nano git git:send-email less
help2man strace nss-certs'
This also lets me add on any ad-hoc packages at the end, like
geg dejagnu expect
However, an actual `guix env' could do a lot more! Like you allude to, being
able to essentially save the options of a `guix environment' invocation would
be great:
$ guix env --edit @test
$ guix env @test -- pytest
But also imagine portable environments (used, for example, for project dev
environments, checked in with the source):
--8<---cut here---start->8---
$ guix env --export @myapp-test --pure -C -f guix.scm --ad-hoc strace coreutils
(environment "@myapp-test"
(load '("guix.scm"))
(ad-hoc-packages '("strace" "coreutils" "findutils"))
(flags '(pure container)))
--8<---cut here---end--->8---
Of course, this isn't entirely reproducible, as packages could change as you
update your Guix, even if you give a version spec (the same issue that exists
for manifests). So, we could pin the channel used to make the environment:
--8<---cut here---start->8---
$ guix env --export @myapp-test --pin-channels ...
(environment "@myapp-test"
(channels (list (channel (name 'guix)
(url ...)
(commit ...)))
(load '("guix.scm"))
(ad-hoc-packages '("strace" "coreutils" "findutils"))
(flags '(pure container
--8<---cut here---end--->8---
which, when evaluated, would internally do what `guix time-machine --channels
file' does.
These environments could then be used like:
$ guix env -e environment.scm @myapp-test
but that's quite long... perhaps we could allow `guix env' to automatically
read a "guix.scm" or "environment.scm" file in the current directory, and make
the environment definitions within available?
...so I definitely think there's room for such a feature in Guix :)
--
Sarah
Re: Batching world-rebuilding changes for the core-updates-frozen branch
Hi, Maxim Cournoyer writes: > Hello Guix! > > Since there's going to be at least this change [0] causing a world > rebuild of the core-updates-frozen branch, I'd like to know if there are > other world-rebuilding but low-risk changes you'd like to see integrated > into the branch. Perhaps we also want to wait for the fix for "cannot build missing derivation" [0] to be pushed and deployed as well? A world-rebuild is likely to cause a *lot* of this, leading to useless CI feedback. [0] https://issues.guix.gnu.org/50040 -- Sarah
Re: Duplicated libxml++ packages
Tobias Geerinckx-Rice skribis: > Guillaume Le Vaillant 写道： >> I just noticed on the core-updates-frozen branch that there are libxml++ >> packages (in gnome.scm) and also libxmlplusplus packages (in xml.scm). >> I checked the sources of libxml++-2.40.1 and libxmlplusplus-2.40.1, and >> it looks like it is the same library. > > Good catch; it is[0]. It's not specific to core-updates, though, nor does any > of them rebuild the world, so I'll deduplicate them on master. > > Kind regards, > > T G-R > > [0]: > https://github.com/libxmlplusplus/libxmlplusplus/commit/f611c14c1f023407e5856891a2ffd7cfebaa5ea5 Ok, thanks. signature.asc Description: PGP signature
Re: Duplicated libxml++ packages
Guillaume Le Vaillant 写道： I just noticed on the core-updates-frozen branch that there are libxml++ packages (in gnome.scm) and also libxmlplusplus packages (in xml.scm). I checked the sources of libxml++-2.40.1 and libxmlplusplus-2.40.1, and it looks like it is the same library. Good catch; it is[0]. It's not specific to core-updates, though, nor does any of them rebuild the world, so I'll deduplicate them on master. Kind regards, T G-R [0]: https://github.com/libxmlplusplus/libxmlplusplus/commit/f611c14c1f023407e5856891a2ffd7cfebaa5ea5 signature.asc Description: PGP signature
Re: PEP 668 -- Graceful cooperation between external and Python package managers
Hi, Am Samstag, den 11.09.2021, 22:36 -0400 schrieb Maxim Cournoyer: > IIUC, PEP 668 is about *warning* a pip user when installing a package > would shadow a system one; it does so by reading a EXTERNALLY-MANAGED > file in the Python library site-packages directory. > > So simply put, all we have to do to enable this future warning in pip > is to install an EXTERNALLY-MANAGED file as a phase in our > python-build-system. Imho I don't think Guix needs to do anything to address PEP 668. PEP 668 concerns traditional distros, in which pip and the distro package manager may both write to the same location (that location typically being /usr/lib). IIUC it does not concern Nix or Guix, whose store paths should already not be written to by pip. Regards
Duplicated libxml++ packages
I just noticed on the core-updates-frozen branch that there are libxml++ packages (in gnome.scm) and also libxmlplusplus packages (in xml.scm). I checked the sources of libxml++-2.40.1 and libxmlplusplus-2.40.1, and it looks like it is the same library. I think we could keep only the libxmlplusplus ones and remove the others. Does someone have an objection? signature.asc Description: PGP signature
Re: eudev deprecation
One more & I'll stop the spam: https://pad.dyne.org/pad/#/2/pad/edit/ngCNROttei-mn3BnW3O1KHdG/ Kind regards, T G-R signature.asc Description: PGP signature
Re: eudev deprecation
…and for completeness: a certain distro has a nascent Libera IRC channel with topic ‘let's keep eudev maintained’: http://reisenweber.net/irclogs/freenode/_devuan-eudev/ Perhaps it will become useful to us. Kind regards, T G-R signature.asc Description: PGP signature
Re: eudev deprecation
Lars-Dominik Braun 写道： Looking at Gentoo’s ebuilds it should be possible to “extract” and build udev from systemd’s sources. That's my understanding as well, but I haven't tried :o) For easy reference, here's the link: https://github.com/gentoo/gentoo/blob/master/sys-fs/udev/udev-249-r3.ebuild And here's the original deprecation announcement: https://github.com/gentoo/eudev/issues/199 Kind regards, T G-R signature.asc Description: PGP signature
eudev deprecation
Hi everyone, it looks like eudev, which we heavily rely on, is dead upstream: https://github.com/gentoo/eudev/issues/199 Looking at Gentoo’s ebuilds it should be possible to “extract” and build udev from systemd’s sources. Cheers, Lars
Re: Batching world-rebuilding changes for the core-updates-frozen branch
not sure this is relevant here, but there is this fix for wrap-script, too: http://issues.guix.gnu.org/40039 Sent from mobile, pardon my brevity. Original Message On Sep 8, 2021, 17:00, Maxim Cournoyer wrote: > Hello Guix! > > Since there's going to be at least this change [0] causing a world > rebuild of the core-updates-frozen branch, I'd like to know if there are > other world-rebuilding but low-risk changes you'd like to see integrated > into the branch. > > If you do, feel free to 'block' the 50358 issue with the changes, so > that I can review them and push them at the same time as [0]. > > Thank you! > > Maxim > > [0] https://issues.guix.gnu.org/50358
