Re: Should we include nss-certs out of the box?
On Wednesday, April 3rd, 2024 at 1:06 PM, Maxim Cournoyer wrote: > Is anyone opposed to having nss-certs in %base-packages? I applaud that plan. Not only that, I think that Guix should warn if you don't have nss-certs in your profile on a foreign distro (with a mechanism to suppress that, ofc) Lacking the nss-certs package causes all manner of trouble and is a stumbling block to adoption. It's practically a dependency; the ability to operate without it is kind of a party trick. Ryan
Re: xz backdoor
On Tuesday, April 2nd, 2024 at 3:23 AM, Attila Lendvai wrote: > https://github.com/Tudmotu/gnome-shell-extension-clipboard-indicator/issues/138#issuecomment-904689439 > > ...and its author actively defends this situation. Yikes. This sounds like a great reason to fork. The author can prefer it his way but it's irresponsible to make that the default. Ryan
Backdoor in upstream xz-utils
I'm reading today that a backdoor is present in xz's upstream tarball (but not in git), starting at version 5.6.0. Source: https://www.openwall.com/lists/oss-security/2024/03/29/4 Guix currently packages xz-utils 5.2.8 as "xz" using the upstream tarball. Is there a way we can blacklist known bad versions? Should we switch from using upstream tarballs to some fork with more responsible maintainers? Ryan
Re: Guix days guix home discussion
On Sunday, March 17th, 2024 at 12:24 PM, Ludovic Courtès wrote: > ‘guix home import’ does exactly that: generate a first configuration > that you may find necessary to tweak. Perhaps the manual should clarify > that? Maybe we should call it "guix home init" then? Describing it as "import" implies to me that a situation where relevant config is not imported would be seen as a bug, or at least as a potential site for improvement.
Re: Guix days guix home discussion
On Sunday, March 17th, 2024 at 12:24 PM, Ludovic Courtès wrote: > I personally try to lower the barrier for Home services, but I think few > people (if any) beyond me review Home services. > > We should expand the ‘home’ team; who’s in? I would like to contribute to Guix home, but haven't been able to get much use out of it myself. This is a combination of two frustrations I've hit: 1. I haven't been able to use Guix Home to migrate my home config across machines. I've done this 3 times since I started using Guix on what I would consider advanced-level (writing Guile, defining my own packages & manifests, contributing patches.) Each time, I've got frustrated with the applicability of what documentation or examples I could find, and ended up migrating the bad old way by copying config files & modifying them as needed. Guix does help me in these migrations somewhat by allowing me to install needed software environments in a non-disruptive way, but I haven't gotten any use out of Home here. For reference, my attempts have been on elementary OS and Ubuntu, never on Guix System. 2. I've desired to use Guix Home on foreign distros to run Guix services (like Docker or Postgres) via Shepherd, but have failed to do so thus far. I read documentation in Guix and Shepherd, and some source code. I've got Shepherd installed & running on some of my machines, but I can't figure out how to use it to run Guix services. Possibly I'm missing something, but I also wonder whether perhaps Guix services are only intended to run on Guix System? I would like to help make Guix Home & services have an excellent experience on foreign distros. I intend to write documentation, blog posts and code to do so. I've been stuck, though, in actually making progress understanding how to accomplish my aims, and every time I've tried it so far I've been in enough of a hurry that I gave up after a couple days' hacking. If anybody wants to pair with me or lend a hand I'd be thrilled to get back to this. Ryan
Fw: Re: Concerns/questions around Software Heritage Archive
[I intended to CC the following to guix-devel but forgot:] --- Forwarded Message --- From: Ryan Prior Date: On Saturday, March 16th, 2024 at 6:36 PM Subject: Re: Concerns/questions around Software Heritage Archive To: Vivien Kraus > > > On Saturday, March 16th, 2024 at 6:13 PM, Vivien Kraus > viv...@planete-kraus.eu wrote: > > > 2. is more difficult, because Guix contributors sometimes change their > > names too, and a commit reading “update my name” is not the best > > solution. If I understand correctly, rewriting the history would be > > understood as a “downgrade attack”, contrary to the ftfy case where the > > developer could rewrite the history without such consequences. Is my > > understanding correct? > > > It's only a problem IMO because we make the decision to treat Guix as an > append-only series of commits and treat any other outcome as a potential > attack. One alternate solution would be to allow provision of an > authenticated alternate-history data structure, which indicates a set of (old > commit hash, new commit hash) tuples going back to the first rewritten commit > in the history, and the whole thing would be signed by a Guix committer. That > way, the updating Guix client can rewind history, apply the new commit(s), > verify that the old chain and new chain match what's provided in the > alternate-history structure & that its signature is valid. Thus verified, the > Guix installation could continue without needing to allow a downgrade > exception. > > Perhaps there are much better ways of handling this, but I propose it in > hopes of clarifying that there are technical solutions which preserve > integrity while permitting history rewrites in situations where it is > desirable. > > I have requested previously that some commits I've provided be rewritten to > update my name. In my case, it's because I've sometimes misconfigured my > email software such that some commits by me are signed just "ryan" or "Ryan > Prior via Protonmail" or similar, rather than my preference which is "Ryan > Prior". > > In my case this causes me no harm and is simply an annoyance, so when I > encountered resistance to rewriting the offending commits, I dropped the > matter, and I still consider it dropped and settled. Even if we developed the > capability to securely present a rewritten history, I wouldn't demand that > such be used to address small concerns like mine. > > However, I know we have at least two trans Guix contributors. Do they have > any commits with their deadnames on them? Not that this is an invitation to > go look; they can tell us if this is a concern worth raising. I include the > detail to clarify that this is not a distant concern. Perhaps they have been > silent thus far for the same reason that I have, because the policy against > rewrites presents too high a barrier? (Or it may not bother them, or maybe > they used their initials which are the same etc?) In any case I think it > would be courteous to develop a procedure by which we could remove deadnames > from old commits, or otherwise remove harmful information from Guix's > development history, should this become a necessity. > > Ryan
Re: Concerns/questions around Software Heritage Archive
On Saturday, March 16th, 2024 at 10:52 AM, Ian Eure wrote: > > > Hi Guixy people, > [...] > I was also distressed to see how poorly they treated a developer > who wished to update their name: > https://cohost.org/arborelia/post/4968198-the-software-heritag > https://cohost.org/arborelia/post/5052044-the-software-heritag I read these posts with interest. It is worth noting that the complained-about organization, Inria, supports Guix as well & has close historical ties to the project (although it is does not have decision-making power here AFAIK.) It is a shame that Inria have treated this matter with such apparent disregard. I have heard folks in the Guix maintenance sphere claim that we never rewrite git history in Guix, as a matter of policy. I believe we should revisit that policy (is it actually written anywhere?) with an eye towards possible exceptions, and develop a mechanism for securely maintaining continuity of Guix installations after history has been rewritten so that we maintain this as a technical possibility in the future, even if we should choose to use it sparingly. Ryan
Re: How would you feel about this derivative logo for Nonguix?
On Wednesday, March 6th, 2024 at 11:37 AM, Luis Felipe wrote: > > > Hi, > > Nonguix would like to have a logo [...] I couldn't help it and suggested to > reuse the GNU Guix logo I like this. There's a clear visual continuity, but with warnings and (in options B-D) part of the Guix horns covered up as well, emphasizing the "non." I had read rms's "install fest devil" idea and immediately thought of it when I saw your options, even without making the connection that the red line was a tail (I thought it was an arrow pointing left?) - it might be an obscure reference to many but I think your execution was spot on in that regard. Not that my say-so carries any weight, but one thumbs up from me. Cheers, Ryan
Re: [bug#62264] [PATCH v2 0/3] Add 'guix locate'
--- Original Message --- On Wednesday, June 7th, 2023 at 10:09 PM, Ludovic Courtès wrote: > > > Hello! > > Here is the “camera-ready” version of the new ‘guix locate’ command > (formerly ‘guix index’) that Antoine and myself have worked on. > I think it’s ready to go. It would be helpful to provide a link to any documentation that's part of this work, as neither "guix locate" nor "guix index" have been discussed on guix-devel previously. I look forward to learning more about this feature! Ryan
Re: Transformations Shell Syntax
I don't like the unpredictability of jgart's original proposal, but maybe something explicit could still look similar. Suppose you could build emacs-ement these three ways: # no transform- this is a version packaged in Guix guix build emacs-ement@0.5.2 # transform using `with-git-commit` guix build emacs-ement@git-commit:8b56efa9387262514daf63151d41c9e111e79567 # transform using `with-latest` guix build emacs-ement@latest # transform using `with-version` guix build emacs-ement@version:0.8.2 A short syntax for transforms would contribute to readability and ergonomic ease. Worth looking into. Ryan --- Original Message --- On Tuesday, May 23rd, 2023 at 5:20 PM, jgart wrote: > > > > What disturbs me with your suggestion is that it reuses the same syntax > > > that is already used for a different purpose. So in a sense you do > > "operator overloading", and the same command line then means different > > things depending on whether the package version is already provided by > > Guix or not. > > > Yes, I see how that can be an CLI smell and "not Guixonic". > > Would be sweet to have something like it but I realize the negative of > dirtying the current API's explicitness to get lower verbosity invocations at > the shell prompt.
Guidelines for pre-trained ML model weight binaries (Was re: Where should we put machine learning model parameters?)
Hi there FSF Licensing! (CC: Guix devel, Nicholas Graves) This morning I read through the FSDG to see if it gives any guidance on when machine learning model weights are appropriate for inclusion in a free system. It does not seem to offer much. Many ML models are advertising themselves as "open source", including the llama model that Nicholas (quoted below) is interested in including into Guix. However, according to what I can find in Meta's announcement (https://ai.facebook.com/blog/large-language-model-llama-meta-ai/) and the project's documentation (https://github.com/facebookresearch/llama/blob/main/MODEL_CARD.md) the model itself is not covered by the GPLv3 but rather "a noncommercial license focused on research use cases." I cannot find the full text of this license anywhere in 20 minutes of searching, perhaps others have better ideas how to find it or perhaps the Meta team would provide a copy if we ask. Free systems will see incentive to include trained models in their distributions to support use cases like automatic live transcription of audio, recognition of objects in photos and video, and natural language-driven help and documentation features. I hope we can update the FSDG to help ensure that any such inclusion fully meets the requirements of freedom for all our users. Cheers, Ryan --- Original Message --- On Monday, April 3rd, 2023 at 4:48 PM, Nicolas Graves via "Development of GNU Guix and the GNU System distribution." wrote: > > > > Hi Guix! > > I've recently contributed a few tools that make a few OSS machine > learning programs usable for Guix, namely nerd-dictation for dictation > and llama-cpp as a converstional bot. > > In the first case, I would also like to contribute parameters of some > localized models so that they can be used more easily through Guix. I've > already discussed this subject when submitting these patches, without a > clear answer. > > In the case of nerd-dictation, the model parameters that can be used > are listed here : https://alphacephei.com/vosk/models > > One caveat is that using all these models can take a lot of space on the > servers, a burden which is not useful because no build step are really > needed (except an unzip step). In this case, we can use the > #:substitutable? #f flag. You can find an example of some of these > packages right here : > https://git.sr.ht/~ngraves/dotfiles/tree/main/item/packages.scm > > So my question is: Should we add this type of models in packages for > Guix? If yes, where should we put them? In machine-learning.scm? In a > new file machine-learning-models.scm (such a file would never need new > modules, and it might avoid some confusion between the tools and the > parameters needed to use the tools)? > > > -- > Best regards, > Nicolas Graves
Re: Caching test results separately?
--- Original Message --- On Monday, March 13th, 2023 at 10:21 PM, Josselin Poiret wrote: > But I would really like for tests to move out of build phases I've mentioned this previously in IRC as well. Fundamentally, it strikes me as wrong that a change which only affects tests, leaving the installed package the same byte for byte, should require a full package re-build. An improvement would be to treat tests, and their pass/fail status, are metadata separate from package builds. In Eelco's thesis, testing is described as a major motivator for nix: but in his construction, nix's role is to produce package builds, and then you run tests on the outputs to decide whether to promote a build into production or not. We should use Guix to create testing, staging and production deployments, not to gatekeep and prevent packages with failing tests from building. Many packages I've created or upgraded had some or all tests disabled because they require a network stack, eg a client library for postgres requires a postgres server. This should be easy to model using Guile and Guix. I would love to contribute to development in this direction. Ryan
Guix home migration
Migrating application settings to guix-home is something we want to make really approachable. Right now it's a relatively new and little-known feature but it could quickly become one of the top use cases for Guix, as a lot of people are interested in declarative application configuration. A free software project to look at for ideas is Mackup: https://github.com/lra/mackup Its strategy is unsophisticated: it moves your configuration files to a synchronized directory in Dropbox (or similar) and replaces it with a symlink. But it's got a great migration story: you run `mackup backup' and it scans for config files for hundreds of applications [1] and automatically migrates them. Whether or not we would want the exact same experience, the overall vision of a single migration command that scans for dotfiles and adds them to your guix home is something we can aspire to. [1]: https://github.com/lra/mackup/tree/master/mackup/applications
Re: Advanced distribution
Hi Octavio! We had a discussion about this last month, and we might make some changes to make it clearer what "advanced" means (or perhaps change the wording.) Here's a link to that discussion in the list archive: https://lists.gnu.org/archive/html/guix-devel/2022-11/msg00298.html Cheers, Ryan P.S. apropos of your email header: this email thread will also be visible on the public Guix archive. For sensitive issues please consider sending to guix-maintain...@gnu.org --- Original Message --- On Saturday, December 10th, 2022 at 3:08 AM, Engineer Octavio wrote: > ---...--- > Este email es para el staff del proyecto Guix. > ___ > Cualquier otra persona no autorizada por mi Octavio Alfredo Toscano Flores > que lo esté leyendo le informo que está violando mi intimidad y privacidad. > ----- > > Hello everyone. > > I was reading. > > The specific URL: guix.gnu.org/es/ > I found the specific text: > "Guix es una avanzada distribución del sistema operativo GNU desarrollada por > el proyecto GNU" > > Also. > > The specific URL: > guix.gnu.org/en/ > I found the specific text: > "Guix is an advanced distribution of the GNU operating system" > > I was wondering. > > Why Guix is an advanced distribution of the GNU operating system? > > Muchas gracias. > Saludos cordiales. > > Ing. Octavio Toscano.
Re: advanced?
On Saturday, November 26th, 2022 at 9:47 PM, Simon Josefsson via "Development of GNU Guix and the GNU System distribution." wrote: > I find use of the term 'advanced' wrt Guix confusing and even mildly > excluding, even though it is wide-spread. [...] Can I use it even if I'm not > an advanced user? What do others think? I'll offer a perspective as a native English speaker who reads and writes a lot about software. tl;dr: the word "advanced" can be offputting and give an exclusive vibe, because of the ways it is typically used in idiomatic English prose written about software. But to a small fraction of people it is the opposite, it is welcoming and inclusive. In software marketing, if a product or solution is described as "advanced," that typically communicates that it considers and caters to demanding use-cases which are beyond what most people face. If you want to reach people who are struggling with distributed system uptime, describing an "advanced clustering solution" could be a good way to connect, for example. In software documentation and configuration, "advanced" is used as shorthand for "this is safe to ignore." Less-technical users feel reassured that they can skip an "advanced" section entirely, never read it, and not miss anything that would be relevant to them. A technical user seeing "advanced" knows that this might be interesting to them, but maybe not on the first read-through before they are familiar with high level concepts; it's safe to skip for now. Many applications have a section of their settings menu labeled "advanced" - this too is a shorthand for "safe to ignore." Many users will never even glance at the advanced settings of any application they use, and even power users will often wait until they have some experience with an application before diving into advanced settings. To a small subset of hackers and techies, "advanced" is a welcome-word: it says, this is something pithy that we included for those who dare to demand flexibility and utility. For those users, an "advanced" software product is likely to be more interesting even if it's hard to use, and they dive into "advanced" configurations immediately in case there's interesting insights about software internals and capabilities in there. This is wholesome and commendable behavior, but IMO folks who behave this way should consider that they are a fraction of one percent and their experience of software is in many ways unrelatable to that of their comrades.
Re: Request: build package with source tarball
On Monday, September 12th, 2022 at 1:29 AM, Olivier Dion wrote: > It already can. > > I use this in my Makefiles: [snip] That's a solid approach with your makefile! I tried it yesterday with just the tar.gz and it didn't seem to work, but probably I misspelled something and then gave up too early. Just tried again and it's working as expected. Thank you! Ryan
Request: build package with source tarball
Hi there! Lately I've been testing distribution tarballs with a workflow like this: - update some software in my source directory - create a distribution tarball - untar to a directory like /tmp/mypkg-src - run: guix build --with-source=mypkg=/tmp/mypkg-src It would be nice to skip step 3 there and just run: guix build --with-source=mypkg.tar.gz Guix should then untar and use the result as the source directory for the build. To soup the process up even further, allow --with-source to take a URL of a tarball, in which case Guix fetches and untars. Then I could write a trivial local microservice which produces distribution tarballs on demand, allowing me to skip both steps 2 and 3. That would be a sweet workflow. Ryan
Re: developing javascript with guix
On Wednesday, July 27th, 2022 at 10:25 PM, jgart wrote:
>
>
> On Wed, 27 Jul 2022 11:33:43 +0200 Maxime Devos maximede...@telenet.be wrote:
>
>
> Hi Maxime,
>
> Hope all is well.
>
> > Let's try not doing anything special:
>
>
> Thanks for the repl example and for trying out a Guix developer js
> workflow for me. Do you happen to know if the same approach works
> for erlang?
>
> I think we should have language developer documentation for
> general orientation of new Guix users. Ryan Prior, another Guix
> contributor/developer has mentioned this idea to me before.
Hey Guix! Since I'm mentioned here, I'll throw in a couple ideas.
First, an issue about unexpected behavior. I tried running this:
guix shell node-sqlite3 -- node <<<"console.log(require('sqlite3'))"
It gave me an error saying it couldn't find the module sqlite3. Turns out it's
because I was using node from my base profile and not from the shell. Running
the shell with `--pure` makes it give a more helpful error, "node: command not
found."
Why isn't node a dependency for node-mersenne though? Is there really a use
case for shipping the source code of a JavaScript library without the
interpreter? At a minimum, can we make `guix shell` warn on stderr if you
create a shell with one or more libraries but no interpreter?
Second, a point about documentation. It's pretty obvious to most of us how to
use JavaScript libraries (or Python, etc) with Guix, modulo small issues like
the above. But Guix has two weaknesses here in comparison to other
language-specific package managers:
## Explanation in context
The language-specific package managers generally don't take for granted that
people know anything about the language, because they're designed to be
accessible to learners of the language. For example, PyPI's explanation for pip
starts with the basic "can you even run Python?" and goes through a bunch of
Python-specific package workflows:
https://packaging.python.org/en/latest/tutorials/installing-packages/
We could write a guide like that with information and example commands specific
to Python packaging, and another for JavaScript, etc. These provide explanation
in context so beginners and people who are confused for whatever reason can see
concrete examples of what you're supposed to do.
## Specificity implies belonging
A Python-specific package manager is full of references to Python, libraries
for Python, tools for Python programmers. If you're doing Python, the PyPI
shouts loud and clear: "you are in the right place!"
Likewise for JavaScript and npm, Ruby and gems, etc. Landing on the pages for
any of those package managers confirms that you are in a place where you will
find information and tools that will help you with your language and package
commons of choice. When you do a search for "MySQL" on PyPI, you only see
Python MySQL packages, not random other stuff. The interface and search quickly
confirm that you have found the right place with the right stuff for you.
Meanwhile, in the Guix docs, everything is abstract. We don't name any specific
library commons or restrict package search to any specific namespace, we don't
even have tags or categories for them. There is no link to Guix documentation I
can give to a Python hacker that assures them, in the way PyPI's website does,
that Guix has the stuff they need and they can find it and make it work. So
Guix requires more faith and experimentation from users, which means a lot of
people will just bounce off it.
I talk to somebody about once a week who says "oh I've heard of Guix and keep
meaning to try it." The project has built up a lot of indistinct good faith
that it has yet to make good on, so to speak. I think we can make a much better
experience for users from the various language library commons if we build
language-specific landing pages with instructions, documentation, and package
search that affirm they are in the right place and will find the right stuff,
and don't make much assumption that the person knows what they are doing.
I'll pitch in on this effort! I have experience with Ruby, JavaScript and
Python packaging and tooling and am to help build out all those areas. Our
emerging teams can help lend some structure to this effort too, I imagine.
Cheers,
Ryan
Re: Teams
On Saturday, June 4th, 2022 at 12:07 PM, Ricardo Wurmus wrote: > let’s add a page to the website that lists teams > and a mail alias for each of the teams That sounds great. What do you think about encouraging each team to write a dedicated intro to Guix from the perspective of that team as well? For example, I assume people who are on the Home or System teams use different workflows than I typically do, and I'd love to learn them. Teams I could contribute to: - python, ruby, golang - DevOps/Docker Cheers, Ryan
Re: Cuirass and SQL
--- Original Message --- On Saturday, May 28th, 2022 at 8:45 AM, Arun Isaac wrote: > There's still the complexity of backing up a PostgreSQL > database How much easier is sqlite3? I host a Postgres server on DigitalOcean with automatic db backup. I've had to restore, it's easy and it works. I also have a few apps in Fly.io using sqlite3, backups are equivalently easy. > Then, there's the added complexity of > maintaining database users and authentication For simplicity in a single-system deployment I recommend running postgres in "trust" mode and listen on a local unix socket rather than exposing it to the network. This allows you to use the same access control for Postgres that you'd use for an sqlite3 db file: file permissions.
Re: Why does sh in the build environment ignore SIGINT and SIGQUIT?
--- Original Message --- On Sunday, May 22nd, 2022 at 8:00 AM, Foo Chuan Wei wrote: > The shell in the environment where packages are built ignores SIGINT and > SIGQUIT. If I add `(invoke "sh" "-c" "trap")` to a custom build phase That executes a shell which traps and then immediately exits. By the next step of the build phase execution it's already gone. The shell isn't ignoring you - it's not running at all. > The resulting [smlnj] executable seems to inherit the > signal dispositions of the shell where the executable is built, with the > result that CTRL-C is ignored at the sml REPL. How would it know what some other process would do in response to a signal? Sounds extremely cursed.
Re: emacs-guix (upstream) needs more love: a survey of repositories, homepage and issues
On Wednesday, April 27th, 2022 at 2:01 PM, John Soo wrote: > Hi Gio! > > I am very sorry I have let it slip. No worries! I am planning this weekend to try out the fixes in 55013 (and try building from upstream savannah; I didn't realize that was different from what we have in guix) and this weekend to see if we can get something working "out of the box." We appreciate your work on getting emacs-guix back into shape! Cheers, Ryan
Re: Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works)
Zimoun wrote: > Today, Guix provides a script that allows to install on any foreign Linux > distribution. [...] Guix provides a “nightly“ VM. And, IIRC, Guix is also > available via upstream Gnome boxes. Somehow, it is already “Guix for > Desktop”, no? ;-) An important bit of context here is that I'm talking about the case where a software engineer is the end-user of Docker (or of Guix,) utilizing it specifically as an interface and a tool to build, test, and deploy software. (This is what I meant by "end-user dev tool" in my email title and I regret that I didn't explain up front in more detail what I meant.) This brings a whole different set of assumptions from the common case where the end-user just wants to run some software and the building & testing are incidental. When I install Docker for Desktop on macOS or Windows, I do not have to first install a VM manager dependency like QEMU or VirtualBox. The installer for Docker creates and manages a VM automatically, which is treated as de-facto immutable and never exposed to the user at all. It is locked down, automatically updated, and doesn't provide the user any way to install new software or make changes to it. It's not like a distro: it provides only what's necessary to run containers, with no desktop, no coreutils, no SSH, no VNC, practically no userland at all. The only point of interaction with the VM is through the Docker daemon. On Windows or Mac when you run `docker build` the client software is connecting to the daemon in the VM, sending it the build context, etc - but the user doesn't have to configure or manage any of this. And thus with each Docker command. Liliana Prikler wrote: >But who are those users of Docker for Desktop? For me, that seems to be a >niche even smaller than flatpak et al. The target demographic is developers who, whether out of preference or for corporate compliance or some other reason, use macOS or Windows on their dev machine but are deploying to GNU/Linux boxen. By standardizing on Docker for Desktop, organizations are able to provide a consistent GNU toolchain to all their developers and operators, smoothing out the differences between platforms and decreasing complexity. I acknowledge that people also sometimes use Docker for Desktop as a Flatpak alternative, to just run some software. And that particular use case is indeed niche. But at companies that use Docker on the server to test and deploy software, every developer who uses a non-free OS likely has Docker for Desktop installed. This amounts to hundreds of thousands of daily users, at least. >Running a full-blown distro inside docker defeats the purpose of docker, which >is to run only the parts necessary to keep your microservice alive. It is uncommon to run a full distro using Docker for Desktop. I wouldn't say unheard of, but overwhelmingly the most common use case is to do exactly what you describe, building and running small containers with a service in them. The value proposition of Docker for Desktop is that you don't have to do the work of managing a VM or even SSH into a VM in order to interact with the Docker daemon. You just install Docker for Desktop and interact with Docker the same as you would with GNU/Linux. Zimoun wrote: > What do you have in mind for smoothing the workflow of end-user running Guix? > I agree that things are lacking for more adoption but I miss what you would > have in mind with “Guix for Desktop”. Some organizations using Docker on the server would be even better served by Guix, and even moreso as our project matures. As Liliana points out, even those who decide to keep using OCI containers can benefit from building them using Guix. But for a variety of reasons organizations commonly have a heterogeneous environment, with GNU/Linux on the server and a mix of free and non-free OSes on the client. They would face a much lower barrier to adopt if we were to offer a "Guix for Desktop" installer that enables uniform developer workflows, such that "guix build -f my-app.scm" works the same on any client, and so on for each Guix command. This would necessarily exclude some commands, like and "guix system reconfigure," which are expected to mutate the user's base system. Installed this way, every interaction with Guix would be in a Guix container, with files from the host system mounted into it. If I ran "guix install coreutils" then the installed "ls" would be a shell script that runs ls inside a Guix shell in the VM, with the current directory mounted into it. This would not be an ideal system for installing and managing software on a non-free OS and I wouldn't recommend using it for such: it's limited, carries the performance penalty of a VM, adds complexity, But for the specific case where the end-user is a software engineer on a non-free OS who is building, testing, and deploying software using Guix, it could be excellent. You'd check out your repo, "guix
Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works)
One side-thread in "Building a software toolchain that works" notes that Guix faces challenges for adoption because it's not readily available to users of proprietary operating systems like macOS and Windows. I've witnessed over the past decade that GNU/Linux development on other platforms has become widespread, in large part due to the availability of the Docker for Desktop application which packages a lightweight, automagically managed GNU/Linux virtual machine running the Docker daemon with Docker client software built for the target platform. A user of Docker for Desktop on a proprietary OS can run "docker" commands which transparently execute commands inside a GNU/Linux container, making building and testing software quite convenient and reproducible without needing to set up cross-compile toolchains or spend time managing VM software. It makes absolute sense to me that Guix is not interested in building a native distribution for the Windows or macOS toolchains. One of Guix System's unique strengths is its adherence to the GNU FSDG and I don't think that's incompatible with making the Guix tools more generally available to end-user devs hacking on software using a proprietary OS. Technically, I think we could use a similar approach to the Docker for Desktop system: a "Guix for Desktop" installs software to create and manage a minimal Guix System virtual machine which automatically updates and reconfigures itself, requiring no manual administration by the end-user. And it would install a Guix client that connects to the Guix daemon running in the VM using a shared socket, enabling users to incorporate Guix transparently into their workflows. I think this would be a compromise for certain, the same way it is for Emacs and other GNU flagship projects that run on non-free systems. On the one hand, it serves to make those systems more valuable, which undermines our cause. But on the other hand it provides a major on-ramp to free software and superior build tooling, positively impacting the practical freedoms available to the end-users who adopt Guix. wdyt?
Fetching sources using Guix (re: Building a software toolchain that works)
One of the side-threads in "Building a software toolchain that works" was essentially this: If I fetch sources for a package using Guix, with the intention to make changes and then build and test the software myself, what should we do with any patches & snippets that are part of the Guix package? There does not seem to be an obvious right answer. One reason is that patches and snippets fall into at least a few use cases: - The upstream package won't build at all as-is using the environment Guix creates, so we apply a patch to enable a successful build. - Upstream vendors some sources into their package, which we prefer to excise using a snippet so that we can do our own dependency management - Upstream includes non-free components, which we remove to build a fully free package - Upstream includes binaries in their package, which we prefer to snippet out so we can build them ourselves At present we don't include any semantic information with each patch or snippet to explain why it is needed. Many have helpful comments; some don't. Would it be feasible or desirable to create a set of "reason" symbols, similar to our "licenses," and attach a reason (or unknown?) to each snippet and patch? Then we can expose meaningful data to the end-user about patches & snippets that are available, enabling an informed choice about whether to apply them when fetching sources. This could also be useful in our own record-keeping, so that we can track the usage of patches and snippets for different reasons. It would be nice, for example, to see a downward trend in the number of patches for build systems that won't work at all without them, either because we improve the logic in our build steps or because we contribute changes upstream to make software easier to build.
Re: Building a software toolchain that works
On Wednesday, March 16th, 2022 at 2:02 PM, Josselin Poiret wrote: > Let me chime in on a specific point. >[...] > I don't think I would've written these patches without Guix's help. This is CRUCIAL to Guix's value proposition: by abstracting away so much of the incidental complexity of software, Guix enables a nimble, carefree mode of hacking where you'll create and improve software that would never have been worth the trouble otherwise. Proposals like David's `guix contribute` play on the strength of Guix as an enabling technology. That's exactly the kind of thing I meant when I wrote "double down." How can I encourage the improvement & implementation of such proposals? A few notions: a. My Guile isn't strong enough to put together a proof-of-concept in Guix as a solo effort. I might be able to write a PoC in concert with a more experienced Guiler. We could schedule some strategy & pair programming sessions to get something on track. b. I could work on a PoC using a language I'm better trained with (elisp, Ruby and JavaScript are my three strongest languages probably.) I don't know how that would be received by the Guix commons, I've felt discouraged in the past to extend Guix unless it's in Guile but perhaps that's a false anxiety. c. I could also provide some funding if somebody has time & skills to create a PoC and just needs the financial incentive. If this is you, reach out. I've been pleased to see ideas resonate in this thread. It makes me believe many of us have some form of this thought in our heads and that by socializing we can bring something fresh to the free software world. What are the next steps?
Building a software toolchain that works
I read a Twitter thread just now, which I'll link and reproduce below, that reminds me of something we're trying to build with Guix. Perhaps it'll resonate with other folks here like it did with me. Jonathan Feinberg wrote at https://twitter.com/pheinberg/status/1503116750203797516 >I literally cannot write software outside of Google anymore. Every C++ project >uses its own build engineering. There's Cmake, Ninja, bazel, configure, emsdk, >etc. There is no reasonable way to make them coexist. > >You can use any 3rd party open source library you like, as long as you use >their build, package management scheme, compiler, what have you. But you >cannot then use any other open source library.You can use any 3rd party open >source library you like, as long as you use their build, package management >scheme, compiler, what have you. But you cannot then use any other open source >library. > >There are 3 things that make it possible to use open source software at Google. >1) We have 100 or so people who do nothing but work on our software building >infrastructure. >2) We have 10 or so people who do nothing but hack on toolchains. >3) If you want to use a third-party package at Google, and it hasn't already >been brought into our system, you can (well, really, must) do it yourself. You >can spend the minutes/hours/days it will take to make just that one project >build in our system. > >But, once you've done so, it will Just Work® with everything else, and the >work you've done will benefit everyone. > >This works because there's always only one version of any particular project >checked in (modulo some special snowflakes that have to apologize and explain >themselves formally in special documents that live in the system with the >code). > >But I've just tried, for the last time, to write a program outside of that >system. It's too frustrating, and I'd rather write songs. This means that my >Wordle (the word cloud, remember that from 2008?) will never happen again. > >I'll also never make anything like Python Mode for Processing again. Just >trying to maintain it means many hours of downloading and configuring the >latest hotness in Java versions, IDEs, build tools, etc. > >Not worth it. My time on Earth is too short. I love how easy Guix makes it to build lots of tricky software, and more all the time. Thanks to everybody who's enabled this amazing work and continues to maintain it! Let's double down on that, and keep thinking of ways to improve the software toolchain for the whole world. Cheers, Ryan
Re: File search
On Friday, January 21st, 2022 at 9:03 AM, Ludovic Courtès wrote: > The database for 18K packages is quite big: > > --8<---cut here---start->8--- > > $ du -h /tmp/db* > > 389M /tmp/db > > 82M /tmp/db.gz > > 61M /tmp/db.zst > > --8<---cut here---end--->8--- > [snip] > In terms of privacy, I think it’s better if we can avoid making > one request per file searched for. Off-line operation would be > sweet, and it comes with responsiveness; fast off-line search is > necessary for things like ‘command-not-found’ (where the shell > tells you what package to install when a command is not found). Offline operation is crucial, and I don't think it's desirable to download tens or hundreds of megabytes. What about creating & distributing a bloom filter per package, with members being file names? This would allow us to dramatically reduce the size of data we distribute, at the cost of not giving 100% reliable answers. We've established, though, that some information is better than none, and the uncertainty can be resolved by querying a web service or building the package locally and searching its directory.
Re: Proposal: Separate the guix repo
‐‐‐ Original Message ‐‐‐ On Sunday, January 16th, 2022 at 4:21 AM, Jacob Hrbek wrote: > Currently it's taking me 1~4 hours (depending on the system without > > outsourcing the load on high performance system) to build the guix > > repository in order to be able to test the contribution and contribute I have this issue too. Whether or not we split the repo, providing lightweight makefile targets that don't build everything would be great. I don't need to build all the localization stuff for every language regularly when I'm only going to be testing Guix in English, and so on with lots of tools I'm not necessarily testing. Ryan
Re: Packing Emacs 28.0.91 with native compilation
Hey André, glad you're working on this!
I have an Emacs package with native-compilation, pgtk, sqlite3, xinput2, and
xwidgets that I call "emacs-edge" and have been using daily with Spacemacs. [1]
Hope you're able to get yours working, I'd love to move back to an upstream
Guix package instead of limping my own thing along.
Cheers,
Ryan
[1] https://github.com/ryanprior/guix-packages/blob/master/testing/emacs.scm#L17
‐‐‐ Original Message ‐‐‐
On Tuesday, January 11th, 2022 at 6:32 PM, André A. Gomes
wrote:
> Hi Guix,
>
> I tried to package Emacs as mentioned in the subject without success.
>
> I'm wondering if someone else has done it already. Note that I have few
>
> experience.
>
> Please find my attempt below.
>
> https://git.sr.ht/~aadcg/aadcg-guix-channel/tree/master/item/packages/aadcg-emacs.scm
>
> A log below.
>
> --8<---cut here---start->8---
>
> configure: error: The installed libgccjit failed to compile and run a test
> program using
>
> the libgccjit library; see config.log for the details of the failure.
>
> The test program can be found here:
>
> https://gcc.gnu.org/onlinedocs/jit/intro/tutorial01.html.
>
> You can try compiling it yourself to investigate the issues.
>
> Please report the issue to your distribution if libgccjit was installed
>
> through that.
>
> You can find the instructions on how to compile and install libgccjit from
>
> source on this site:
>
> https://gcc.gnu.org/wiki/JIT.
>
> error: in phase 'configure': uncaught exception:
>
> %exception #< program:
> "/gnu/store/vx6vfbmmazvfi7vp8xyjn2mcyylvw9gn-bash-minimal-5.1.8/bin/bash"
> arguments: ("./configure"
> "CONFIG_SHELL=/gnu/store/vx6vfbmmazvfi7vp8xyjn2mcyylvw9gn-bash-minimal-5.1.8/bin/bash"
>
> "SHELL=/gnu/store/vx6vfbmmazvfi7vp8xyjn2mcyylvw9gn-bash-minimal-5.1.8/bin/bash"
>
> "--prefix=/gnu/store/ljvhsyd91fc307r4chbrzkd5r7zvjgvp-aadcg-emacs-28-pretest-28.0.91-0.d193801"
> "--enable-fast-install" "--with-native-compilation" "--with-modules"
> "--with-cairo" "--disable-build-details") exit-status: 127 term-signal: #f
> stop-signal: #f>
>
> phase `configure' failed after 9.7 seconds
>
> --8<---cut here---end--->8---
>
> Thank you.
>
>
> --
>
> André A. Gomes
>
> "Free Thought, Free World"
Re: Guix Documentation Meetup
‐‐‐ Original Message ‐‐‐ On Friday, December 10th, 2021 at 10:40 PM, Blake Shaw wrote: > tldr: is there also room to discuss contributing -- and possibly doing a > sizeable makeover to -- the Guile documentation? Absolutely. The Guile docs are unusable and make Guile a pain to work with. I say this as an experienced lisp & scheme user with decades of experience now in elisp, racket, and clojure. After bouncing off of guile projects for years, last November I decided to do Advent of Code in Guile to force myself to finally get the hang of it & get productive. I gave up after a week, every task was unpleasant and I was reinventing basic language features because I couldn't find out where/if they were implemented in some obscure SRFI or ice-9 module. Like you wrote, the code I'd finally end up was fine, the language itself seems nice, but it's just plain inaccessible. I've found the Guile IRC channel to be polite and encouraging, but also very self-satisfied, which makes it hard to feel heard as a Guile hacker who's struggling. I hesitate to tackle any kind of nontrivial problem with Guile because I have no confidence I will find tools that save me time; I'm proficient with a half dozen other languages, including multiple lisps, which provide much better support. So even though I really want to learn Guile,because of Guix, Shepherd and other cool software written in it, I'm no more likely to choose Guile for a software project today than I was 3 years ago when I just started learning it. When I talk to experienced hackers in the Guile community I get the sense they've just accepted that yeah, the only way to get anywhere is to cold memorize the most popular ~80 SRFIs or implement everything you need yourself. One person I talked to was like "oh yeah Guile's great, you just have to implement your own standard library like I did." I'd love to hear your talk, if you're up to present at the Guix meetup I'll definitely come and listen. I'm also happy to do what I can to help drive Guile adoption, create a great learning experience around it, and finally start to build the language community that Guile is lacking. Cheers, Ryan
Re: Tricking peer review
On Monday, October 18th, 2021 at 7:40 AM, Ludovic Courtès wrote: > Hi Ryan, > How would we define “bad” though? A definition isn't necessary, this can be an "I know it when I see it" thing. If we have an oops or discover an issue, and say oh darn that lives in the repo forever now, we'd be able to leave a note to all who try in the future to visit impacted commits that all was not well. Some of this is already captured by our CVE scanning feature, but other things (like your hypothetical "somebody snuck a bad `sed` in!") would benefit from yet more explanation. We don't need a perfect and complete definition of "bad" to agree that any commit where `sed` is actually `grep` (or malware) is a bad commit & merits a warning. This should not interfere with people who want to keep using their pinned version of Guix & aren't impacted by the bad package, which remains useful as you note.
Re: Tricking peer review
‐‐‐ Original Message ‐‐‐ > A "bad" commit might still be perfectly fine to fetch certain things from if > they're unaffected by it The database could store a comment with each "bad" commit hash to help people decide if they're affected. It could even go further and include a list of tainted packages, so you could programmatically determine whether one of them is in your dependency tree. > you're now tasked with the job of keeping the list of bad commits safe > somehow. Right now afaik Ludovic's key is the root of trust (is this still true?) so I imagine we'd sign the list too, with that key or some other key signed by it. > In some situations resetting a branch might work, but obviously not for > months old sleeper commits. Not sure what you mean by this, can you explain?
Re: Tricking peer review
On Friday, October 15th, 2021 at 10:03 PM, Liliana Marie Prikler wrote: > > On the plus side, such an attack would be recorded forever in Git > > > > history. > > On the minus side, time-machine makes said record a landmine to step > > into. I've suggested this before and this seems like a good time to bring it up again: can we create a database of known "bad" Guix commit hashes, and make time-machine fetch the list and warn before it'll visit one of those hashes? This would resolve the land-mine problem and generally de-risk our git tree, which is maintained by fallible volunteers who will occasionally push tragic commits.
Re: On the naming of System and Home services modules.
On Wednesday, September 15th, 2021 at 8:47 AM, Andrew Tropin > People will be trying to use home services inside operating systems, and > configuration record for system services inside home services. I think it will be a dismal design failure if we cannot make this just work the way people would expect. Why should we accept that a service which can be run as your user (a "home" service) cannot be run as the system, or vice versa? Perhaps there are some services that only make sense on the system (for example, I don't suppose a home service defining Linux kernel modules would be appropriate.) So for those corner cases perhaps we must allow marking home-only or system-only services, and make it an error to put one in the other's place. But isn't it the common case that a service declaration can be part of the home or the system, and this merely changes some details in how the thing is run and what fields are required for its configuration? Ryan
Named environments
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
Re: How did you handle making a GNU/Linux distribution?
> [I want to bootstrap] all binaries related to creating a GNU/Linux > distribution, such that I can reproduce an exact OS, Racket installation, and > Xiden instance. I want a trusted initial state on GNU/Linux. Seems like the easy path for you is to package Xiden for Guix, and then construct a system definition (using Guix System) that includes Racket and Xiden in its default set of packages, and finally use Guix to build system-images for that target system. To do this does not require that you can run Racket on the Guile VM. The target system-image doesn't even need to have Guile or Guix installed on it at all; it can just serve as a bootstrapped base and you can build from there to your final desired state. I'm happy to explain or assist with any part of this process, and I imagine others on this list would be as well. Designing your own bootstrap and rewriting everything in Racket, or waiting for a suitable Racket-on-Guile implementation, do not seem necessary at all to reach your stated goals. Hope this helps!
Transform options should error on nonexistant targets
I learned today that Guix will chug happily along applying a transform to a nonexistent package. For example, I can run: guix environment --with-latest=not-exist --ad-hoc which This shows no warning or errors. I think it would be beneficial to show an error & bail if the target of a transformation is a package that doesn't exist, as this is likely indicative of an error. What do you think?
Re: Removal of Python 2?
On Tuesday, June 22nd, 2021 at 6:53 AM, Hartmut Goebel wrote: > Am 06.06.21 um 21:44 schrieb Lars-Dominik Braun: > > > 3. Determine the fate of Python 2, which is probably broken through this > > > > patch set. Shall we remove it entirely? Is it worth to keep support? > > Python 2 is dead, dead, dead like the parrot and end-of-prolonged life > > as of more than 1 1/2 years. Anyhow, there might still be quite some > > software not ported to Python 3 after 10 years. So I'm afraid we need to > > keep Python 2. Python 2 is no longer supported, but the Tauthon project [1] is continuing support and backporting features from Python 3. We should consider packaging Tauthon in Guix and updating packages to depend on it. The Python project has promised there will never be a Python 2.8 release [2] but considering the huge body of extant Python 2 code, if we can get consensus within Guix I think there would be value in continuing to support python2 packages via Tauthon. [1] https://github.com/naftaliharris/tauthon [2] https://www.python.org/dev/peps/pep-0404/
Re: Telemetry on by default kitty
On Sunday, June 13th, 2021 at 7:04 PM, Leo Famulari wrote: > Yeah, I agree that telemetry is a problem in addition to being valuable > > for developers. I've been encouraged by the recent progress in differential privacy that opt-out freedom respecting telemetry may be possible. I think this needs to be discussed and coordinated on a platform level and offered as a standard feature for packages on the platform, rather than something app developers have to implement on their own in each instance. An easy API to discover whether you have any packages that could be upgraded would be very handy as well. Currently I find this information by running `guix time-machine --branch=master -- package -u --dry-run --no-grafts` but this is imperfect, takes a long time to run, and doesn't inform me whether there's upstream package updates that aren't packaged in Guix yet but that I could use with a package transform.
Re: [PATCH RFC 0/4] Getting rid of input labels?
On Wednesday, May 26th, 2021 at 2:02 PM, Ludovic Courtès wrote:
> > Could the new syntax accept both variables and specifications, e.g.,
> >
> > (list "glib:bin" foo "bar@2.3")
> >
> > ?
>
> No! I mean, yes it could, but no, I don’t think that’s a good idea.
>
> :-)
>
> In terms of API, I prefer clarity; in this case, I think inputs should
>
> be a list of packages or other “lowerable” objects, rather than a list
>
> of “anything” that could be magically interpreted at run time.
I agree with this, a list of potentially ambiguous "any-type" inputs seems
fraught.
I think there's an opportunity to avoid the need to "fall back" to the status
quo, though. I picture a structure for inputs that has three cases, trivially
decided based on data shape:
- a bare symbol, eg '(tzdata glib)
this is translated to `(("tzdata" ,tzdata) ("glib" ,glib))
works the exact same if the symbol is an =origin=, you get the name of the
symbol quoted followed by the value of the symbol.
- a 2-tuple, eg '(tzdata ("gnome-lib" glib))
when we encounter a 2-tuple, we use the first value as the label and the
second as the value.
so this becomes `(("tzdata" ,tzdata) ("gnome-lib" ,glib))
- a 3-tuple, eg '(tzdata ("glib:bin" glib "bin"))
when we encounter a 3-tuple, we use the first value as the label, second as
the value, and third as the output name.
Following this convention, the inputs for most packages will be a list of bare
symbols, and packages which need custom labels and/or outputs for some inputs
can get them with little effort.
Cheers,
Ryan
Hero culture among Guix maintainers
Hey Guix. There's a specific thing I'm motivated to address after the recent security incident with the "cosmetic" patches & all the fallout of that. In one of the comments that lead off that thread, Mark asked "does anyone else find it worrisome that Raghav has commit access?" I speculate this comment may have predisposed some people to read subsequent comments from Mark as harsh or suspicious. I distinctly remember reading that message and thinking "oh Mark is not amused." I'd write a message like that if I'd already tried privately to resolve a person's practices and they'd been resistant, causing me to give up on them and leaving me feeling little choice but assuming bad faith. I don't know what history the participants in that incident had with one another, I don't follow the list or know everybody well enough to have any knowledge or good guess. One way or another, part of the subtext I got from that thread is that Mark, an established and respected senior contributor here, believes making an error like the one Léo and Raghav made is beneath the level of somebody who's entrusted with membership in the committer group. That reminds me of a common attitude I've seen in operations at a lot of companies, that ops are heroes who take their duties very seriously and feel an extreme responsibility to follow procedures and avoid using their power destructively. That attitude is a liability at any organization, because we're all fallible and guaranteed to fault on occasions, but I think especially so in a high-trust inclusive atmosphere like what Guix has been building. I noticed that Léo joined, got really engaged with improving the software, and was quickly accepted as a committer, which I thought was really cool. I haven't applied for commit access myself yet, both because I have anxiety about acting out of line and thus want more time to learn the norms of the community, and also because I feel reasonably at ease with the tools and processes for non-committers to contribute. But I saw that and thought it was a great sign that a committed contributor like Léo was able to gain the group's trust so quickly. It's a strength and would be a shame to lose that. But if everyone who's entrusted with commit access is also expected to live up to the heroic responsibilities of the classic ops/sysadmin role, then I think we're setting people up for failure. Ops at the best companies are guaranteed to make mistakes, and they have the cultural training to be Very Sorry about it and Learn Their Lesson and so on. But how do we expect every committer to a volunteer open source project to behave that way? Blaming a volunteer for a bad commit, calling them out on the mat to fess up and say they're sorry, is big "blame the intern" energy and it's ultimately not conducive to our security as an organization. I think that's still true even if you assume good faith and use only factual statements throughout. It felt to me like Mark was expecting (demanding?) a certain cultural performance from Léo: acknowledgement of what was done wrong, contrition for his part in it, and a promise not to repeat it. This is typical in ops organizations, but it's not necessarily humane, and I don't think it's a reasonable expectation in a volunteer project. A reexamination of the hero culture among the Guix developers might be in order to avoid similar confrontations in the future. What does it look like to step back from hero culture? One tool I've used working for paranoid security organizations is to require at least two signatures/sign-offs on any merge to a "protected" branch (like master or core-updates,) one of whom has to be part of a "security ops" subgroup who take on responsibility of this extra review. This pratice works on the simple acknowledgement that any given committer is fallible and two heads are better than one. It's impossible to know for sure, but I imagine this practice would have caught the mistake in Léo's commit to core-updates, and might have avoided a lot of anxiety. Some of Christopher Baines recent work on visualizing the impact of commits could also help aid this review task. I'd also be interested to see a mechanism for marking commits in the "protected" branches as vulnerable, such that "pull" and "time-machine" can give a warning (or refuse to use those commits.) This might make occasional bad commits less catastrophic and thus reduce anxiety, allowing us to maintain a safer git tree without having to rewrite history or maintain heroically high standards of judgment about every commit. Cheers, and an honest thank you for everybody's thoughtful messages this past week! Ryan
Re: Leaving the GNU Guix community
On Thursday, April 29th, 2021 at 11:43 PM, Leo Le Bouter wrote: > I feel like what has happened is really a disaster, I don't feel like > contributing to GNU Guix anymore in the future. Hey Léo, thank you for writing & for all your contributions. As a security professional I feel you deeply on the points you brought up and see how it would be frustrating for you to continue. Hope to catch you around & continue hacking together sometimes, it's been a pleasure! Ryan
Re: Organizing Tui Apps
On April 23, 2021, Leo Famulari wrote: > On Fri, Apr 23, 2021 at 10:00:14PM +0200, Leo Prikler wrote: > > Spreadsheets sounds fine to me, but I think the most important ones > > (libreoffice and org-mode) are already excluded from that module for > > obvious reasons ;) > > Perhaps an even more generic "office" module might be better, > because > > then we could at least add some small word processors to it, WDYT? > Or > > maybe sc-im already fits as-is into textutils if you squint hard > enough > > My main objection was about moving packages. So whatever module you > create is fine, but let's not start moving libreoffice and org-mode > around. As the person who originally suggested organizing tui-apps into a file, I'd envisioned it as being sort of like its own desktop environment. So similar to how we might put Gnome (GTK) apps and KDE (Qt) apps together, we might put tui (ASCII terminal) apps together. I am not upset if that's unconvincing to others & will happily drop the proposal if it's not useful, I never intended for it to become a drawn out discussion. It also makes sense to me that we might organize things by programming language or by function, those each have strengths as strategies. Ryan
Re: OUTREACHY INTERNSHIP - INTRODUCING MYSELF
On April 14, 2021, obaseki osakpolor wrote: > Hello everyone, [snip]Â Hi Osakpolor, I'm glad you found Guix delightful so far! I've also been working on learning Guile, the folks in #guile on Freenode IRC chat have been helpful. Welcome! Ryan
Re: Meta guix: making money with GNU Guix: slightly off topic
On April 11, 2021, jgart wrote: > package fosspay for guix and write a service for it Nice idea, that looks like a really useful little service. If any Guix maintainers are supported by community donations, send your links so we can pitch in!
Re: guix home
On March 14, 2021, Joshua Branson wrote: > Andrew Tropin writes: > > > There is an implementation of `guix home` subcommand, which behaves > > similar to `guix system` Thanks for sharing this Andrew, it looks awesome & I'm going to give it a try! What do you think about changing the command? It manages user files, user services, user environment variables, the lifecycle of user sessions. So we could have "guix system" for system-level things, and "guix user" for user-level things. Similarly, many of the services you describe sound to me like they would be easier to understand what they do with names like "user-service," "user-environment-vars," etc. I feel Guix needs something like this upstream. Whether this is the right implementation or not I'm not qualified to judge, but I'll read the source code and see what I can learn or contribute! Ryan
Re: Discover GNU Guix eco-system with awesome-guix!
On February 13, 2021, Hartmut Goebel wrote: > Am 09.02.21 um 17:16 schrieb Léo Le Bouter: > > Commonly awesome lists are used to share links to all things related > to > > some topic or some software > > I wonder why not just calling it "Link list" then? [This] would be > much > easier to understand for non-nerds. Awesome lists are "a thing." A number of people maintain "awesome awesome" lists, which list other pages with "awesome lists." The best known of these "awesome awesomes" is https://github.com/sindresorhus/awesome which has over 152,000 stars and 19,900 forks on GitHub and almost a thousand commits. For my fellow recursion enjoyers, there's also an "awesome awesome awesome" list which lists these lists of lists: https://github.com/t3chnoboy/awesome-awesome-awesome So, while saying "link list" is fine and understandable, there are many people who specifically create and seek out "awesome lists" and find it easier to share and discover such lists under the less generic name. Ryan
Mitigating "dependency confusion" attacks on Guix users
Hi Guix! I've been digesting this piece, published hours ago, describing dependency confusion attacks that revealed severe vulnerabilities at many major organizations: https://medium.com/@alex.birsan/dependency- confusion-4a5d60fec610 Guix users already have a few mitigations against this sort of attack. Most importantly, no substitute servers or channels are installed by default which allow arbitrary uploads by community contributors. That feature of the affected public registries (npm, pypi, rubygems) is so convenient, but contributes to this kind of attack. This is a great motivation for people to move to Guix from those other package systems. However, I'm still thinking about how to attack Guix users. Somebody who adds an internal channel for their own packages could still be vulnerable to a dependency confusion attack via a compromised or manipulated Guix maintainer. The target of the attack could install packages they believed would be provided by their internal channel but actually get another package provided upstream. The degree of vulnerability increases further with each channel used, with each channel maintainer becoming another potential vector of compromise. How can we make this kind of attack even more difficult? What comes to my mind is that we should encourage (require?) people to specify the channel name a package belongs to, if it's not the "guix" channel. So instead of referring to "python-beautifulsoup4" (ambiguous: is this from my channel or upstream Guix?) we say that "python- beautifulsoup4" always means that package from the "guix" channel and a version provided by my channel called "internal" needs to be called for explicitly, like "@internal/python-beautifulsoup4". Cheers, Ryan
Re: PowerShell core?
On February 2, 2021, "Nicolò Balzarotti" wrote: > This post seems just M$ propaganda, more than a "Is anybody working on > the > inclusion of Powershell?" For what it's worth I didn't read it that way. I use PowerShell and have spent some time looking into what it would take to build .NET Core [1] in Guix. It uses expat license [2] & would unblock lots of useful software, including PowerShell. There's a developer guide [3] with build instructions. It seems like it ought to be doable. If you want to get PowerShell into Guix I support that goal (with any patches necessary to remove telemetry & any nonfree bits, of course) and would be happy to provide assistance and encouragement. I think packaging Core CLR and the .NET Core tools is the first step there. Cheers, Ryan 1: https://github.com/dotnet/core 2: https://github.com/dotnet/core/blob/master/LICENSE.TXT 3: https://github.com/dotnet/coreclr/blob/master/Documentation/building/linux- instructions.md
Re: bug#45919: [PATCH 0/8] Exporting a manifest and channels from a profile
On January 30, 2021, "Ludovic Courtès" wrote: > Actually, part of the code would be shared anyway, so we could always > go > with ‘--export-manifest’ first and think about adding the extra files > later. (Though I’m still unsure about these extra files, TBH.) I do like the extra files. It feels cozy to me, like you have your little profile directory and it has a manifest and a list of channels in it, that makes it feel more complete. Like having the family pictures on the wall. The question of what happens if you don't update a profile for a long time and how Guix handles those files moves on is a good one. I think those files should have an indication in there of what version of Guix was used to produce them, such that you can time-machine back to ensure you're compatible. I don't think there's much drawback to having both the auto-generated files and a command that generates them. That seems more discoverable - you might happen across the files when you poke into a profile, or you might notice the command while reading the docs or the help output. Glad to see this capability land any which way, this is something that comes up often! While we're considering putting a manifest in the profile, is this a good time to also bring up the idea of renaming the "manifest" file? It confuses more people all the time. I'd be inclined to rename it "profile-metadata" or "lockfile".
Re: Questions regarding Python packaging
On January 25, 2021, Lars-Dominik Braun wrote: > Being able to demote setuptools and pip > to ordinary packages is merely a side-effect, because they’re not > essential any more. I didn't read all of PEP 517, does it deprecate bundling pip with Python? My understanding was that it just gives maintainers more options and makes setuptools less of a de-facto standard. I'll read it more thoroughly later and see if I missed some important info there. Anyhow, even if a PEP says so, people's expectations to be able to use pip will not disappear suddenly. It's part of the expected interface to Python & I imagine removing it has the potential to cause much confusion. > Your mail seems to be incomplete, it stopped after: > > Also, for what it's worth, we already have python-minimal which > doesn't > > have pip, and it's only Ah darn, I'd meant to write it's only a little bit smaller, and I'm interested to see where we can slim down the Python closure but others have managed to do so without cutting out pip & setuptools. All this being said, I'm not a huge fan of pip & setuptools, I like Guix because it frees me from having to think so much about such things, so I hope this doesn't come off as a defense of the tools themselves. I mean to defend the many Python users who have been trained with a certain set of expectations about the interfaces a Python package provides.
Re: Login to a guix container
On January 24, 2021, Pjotr Prins wrote: > I was just thinking that it should be possible to login with ssh into > a GNU Guix shell running in a container that gets fired up by the > sshd. I am thinking about a safe shell for fetching files. If this > works no chroot setup is required. > > Or is this a really dumb idea :) I haven't seen any serious audit investigating security properties of Guix containers. I do not think it's dumb to try this as an experiment, but I do think it would be malpractice to trust user data with this system before appropriately thorough evaluation.
Re: Questions regarding Python packaging
On January 23, 2021, Lars-Dominik Braun wrote: > [...] Remove pip and > setuptools from python (saves almost 20MiB from the closure and avoids > weird conflicts between python’s setuptools and python-setuptools) and > turn them into (almost) ordinary packages. I think if we do that then Python will need a treatment similar to GCC, where we don't expose the package and instead offer a compound package (could be called "python-toolchain" or just "python") which includes pip and setuptools. The last decades of python packaging have trained people that when you install python you get pip and setuptools as well, I think we should not try to be too clever and violate that assumption. Also, for what it's worth, we already have python-minimal which doesn't have pip, and it's only
Re: Emacs-Guix repository location moved to Savannah
On January 11, 2021, John Soo wrote: > Hi Guix! > > Emacs-Guix has a new home! I just pushed > a42f66cb40a9e60611f429a403b08dbed29bae02 to Emacs-Guix on Savannah. Thanks and congrats! > If you have a command you want fixed, please let me know and I will > priortize it. How do you feel about removing commands that nobody feels like fixing? It might help Emacs-Guix build a reputation for reliability. > What do you think about having conversations about Emacs-Guix on guix- > devel? I think it's a good idea. Conversing regularly on this list will keep people abreast of what state things are in. Moving conversation to a dedicated channel likely means nobody would read, which disincentivizes writing. If discussion on this list reaches a level of volume where it's annoying, that's the signal to explore alternate channels.
Re: bug#45644: closed (Re: [bug#45644] [PATCH] gnu: esbuild: Update to 0.8.29.)
‐‐‐ Original Message ‐‐‐ > By the way, your patches show that they are authored by "Ryan Prior via > Guix-patches via guix-patc...@gnu.org". Is that the correct email address? No, the correct email address is rpr...@protonmail.com There's maybe 15 commits in Guix that have that incorrect email address. I'm not sure where it comes from or how to get rid of it. I send my patches by running a command like: git send-email --to=guix-patc...@gnu.org --suppress-cc=self 0001-gnu-esbuild-Update-to-0.8.29.patch Git has my correct email address: $ git config user.email rpr...@protonmail.com So I have to imagine that either Protonmail or your email server are changing the email address. I don't know if it's possible with the commit-signing system you have in place to rewrite Guix repo history, or whether it would be worth it, but it would be nice to have my actual email on my commits instead of the weird munged one. If there's some behavior I can change to keep it from happening again the future I will certainly be flexible. One thing I'm going to try (unless there's any objection) is to try sending email through a third party like mailgun instead of using Protonmail's SMTP server. If it's confusing or triggers some kind of fraud prevention mechanism to get e-mails to the list that have my Protonmail address on them but aren't actually from Protonmail's server, then the next thing I could try is to request a gnu.org email address for the purposes of contributing to GNU software. Let me know what you think! Ryan
Re: How would packaging Steam-proton games be received?
I don't know in depth how Proton works internally, but I think it includes non free DLLs, including DRM support, to improve compatibility with Windows games. If my understanding is correct, shipping Proton and games that depend on it as part of Guix would be a tacit endorsement of proprietary software that exercises unjust control over users. The GNU project, as a matter of policy, does not recommend non free software components, or free components like DRM that are exclusively useful for restraining user freedoms, so that may be a dead end. I like your energy in this thread though and agree that it would be great if we could help gamers break out of the ugly Steam ecosystem. Itch is an independent game distributor and they also publish all their client code as free software: https://github.com/itchio Bringing Itch to Guix might be an interesting project, if we could find a way to modify the client so that it does not recommend any games that are not free software. There's a healthy and growing list of such games here: https://itch.io/games/tag-open-source We might have to build our own game discovery portal to replace the upstream itch.io storefront, but that would be a really nice thing to have in general. Itch has its own tools for game developers to build their game and ship updates to their users. For example, they designed their own protocol for shipping new game builds using minimal resources: https://github.com/itchio/wharf It would be beneficial if Guix could learn some of Itch's tricks, to support fast moving projects that want to ship frequent updates to users.
Re: guix pack file enumerator?
On December 14, 2020, "Ludovic Courtès" wrote: > Here’s another idea: allowing ‘guix copy’ to talk to a “raw” remote > store—i.e., just /gnu/store + /var/guix/db accessed over SSH. > Hmm that amounts to implementing a subset of the daemon. This reminds me of the much-loved "agentless" model of software deployment as practiced by Ansible. [1] To provision, configure, and deploy using Ansible all you need on the target machine is Python and sshd. It copies its tools over, does its work, then cleans up after itself. If Guix could deploy to any machine with Guile + sshd that would be a pretty compelling story. If you could also substitute perl or python or something more ubiquitous, that would be even stronger, at the cost of decreased code re-use. Best of all would be a mini-daemon we could cross-compile for the target architecture, scp over as a single file, execute there to carry out the rest of the task, then delete if no longer needed. This approach is used to great effect by the Mgmt automation tool [2]. [1] White paper (pdf, 5 pages) https://www.ansible.com/hubfs/pdfs/Benefits-of-Agentless-WhitePaper.pdf [2] https://github.com/purpleidea/mgmt/
Finding versions of packages (was: [outreachy] Walk through the Git history)
Hi there! I've been following the "guix git" discourse with interest because I know a lot of people who care about pinning packages to specific versions and selecting specific versions of software to install. This constituency currently relies heavily on systems like rvm, nvm, and conda to manage the available versions of libraries and runtimes they care about. The proposal to add a "guix git" command to help find old versions of packages seems unnecessarily indirect to me. Certainly you can learn interesting things about the history of Guix packages using the git log, but that doesn't address the questions "which versions of this software are available and how to I use them" except via an abstraction that depends on the operator's tacit knowledge, including what "git" is and how to read git commits. We can do better. I propose a different approach: the "guix versions" subcommand provides direct answers to practical user questions. - What package versions are available? - How do I use them? - Which versions are known to be vulnerable? - Which have available substitutes? For example, the command "guix versions esbuild" can provide this output: name: esbuild version: 0.8.21 guix-hash: eee3af86c7 name: esbuild version: 0.8.19 guix-hash: 6374a25357 name: esbuild version: 0.8.16 guix-hash: 8c3caf9c5d vulnerabilities: cve-2020-1337, cve-2019-1024 ...and so on. Then, to make the output directly actionable, we extend Guix to accept recfile manifests following the same structure, such that given the following file "packages.rec:" name: esbuild version: 0.8.19 guix-hash: 6374a25357 name: python- html5lib version: 1.1 guix-hash: 6374a25357 …we can use those exact packages using "guix environment -m packages.rec", or find which of those packages have substitutes using "guix weather -m packages.rec" I make this proposal because I perceive the following advantages: - It makes no the assumption that the operator knows what git is, cares about the internal git structure of Guix, wants to read git commits, or wants to master the details of the internal "inferiors" mechanism we use to provide this functionality. - It answers directly the operator's practical questions rather than providing oblique advice which depend upon the operator's tacit knowledge. - The user can act immediately upon the output of the command to create a manifest that represents the software they want to use.
Re: guix pack file enumerator?
On December 6, 2020, Ricardo Wurmus wrote: > What do you think about adding an output format that is no format at > all > but a file enumeration printed to stdout? That way I could use “guix > pack” to produce a list of files to transfer and use that to transfer > only the unchanged files. Alternatively, perhaps we could have a > “directory” format that merely copies (or links) the files to a new > directory root. These suggestions comport nicely with the Unix-philosophy and something like that should probably be implemented for people who want to build their own deploy systems like you're describing. Additionally, I think that the use-case of "deploy this software to some server that doesn't have Guix installed" is important enough that we might want to support it explicitly such that "guix deploy" does the right thing, doing minimal work to bring the target deployment up-to- date. Is that feasible?
Re: Staging branch
On December 6, 2020, Leo Famulari wrote: > Are there any other changes we should make on [staging]? It would be great if we can update the default Ruby to 2.7.2. Is there a process for updating Ruby I can follow to help out?
Re: Getting rid of the mandb profile hook?
On December 5, 2020, "Ludovic Courtès" wrote: > many actions should be done lazily, in particular populating caches. Absolutely. > I’m thinking we could get rid of the mandb hook. Please. > 1. Provide a ‘man’ wrapper or modify the ‘man-db’ package such that > the database gets built on the first use of ‘man -k’, unless it’s > already up-to-date. I vote for this one. Anything work we can defer to make package operations near-instantaneous will help me make Guix a seamless part of my computing workflows. As things stand, adopting Guix comes along with regular "pause to wait for Guix to think about something you probably don't care about" breaks.
Re: Questionable "cosmetic changes" commits
On December 4, 2020, Raghav Gururajan wrote: > I can tell you that those cosmetic changes I made were 100% > irrational, useless and noisy. That's certainly a way to frame it, but I'd like to hold some space for the idea that the things we neuroatypical people do to manage and satisfy our own unusual perspectives are not irrational or useless if they make sense to us and serve a purpose for us. > Due to [clinical conditions], if the packages I am editing is not it > in a specific way, I am unable to focus properly. That too, if I am > working on multiple package definitions and if each pack-defs are > arranged in different way, it is very very hard for me. That is an interesting use-case I hadn't considered, but a valid one, and it gives me ideas. I'm going to experiment with some tools to make this feasible. Consider the tooling for Unison[1] which reduces code churn in a number of unique ways.[2] It can store programs as abstract syntax trees rather than plain text files, and it's content-addressed, referring to functions by their hashes rather than their fixed names. As a programmer that gives you the freedom to choose names and language syntax that suit you without imposing on others to follow suit. Due to the functional paradigm and technical structure of Guix, I think we can build some of the same capabilities in our tooling. Like Unison functions, our package definitions are reduced to a declarative content- addressed form, from which a textual definition could be generated again using a reverse process. By such a process, you & I could edit package definitions in whatever textual form suits us individually without having to agree on anything, not even the names of symbols. Then we can use a tool to automatically canonicalize our code into the form most widely acceptable to the community when it's time to submit a patch. Taking this idea to its logical conclusion & building on Guile's multi- language-syntax paradigm, I can picture using a futuristic tool to edit package definitions in Emacs lisp or JavaScript, again without requiring that anybody upstream adopt those languages or even recognize that I'm using them. I'll see what I can hack together for a naïve implementation of this concept and present it for review. > Moving forward, I will try hard not to do this. But can I ask you all > to allow these cosmetic commits for my existing projects (i.e. commits > from wip-desktop and pidgin patch-set) please? It doesn't bug me, but I know it does bug other people and imagine we want to avoid creating unnecessary review work for people who follow the commit stream. > I understand that these commits were a burden to everyone and my > sincere apologies for that. I appreciate the grace and consideration you brought to your response & all your contributions to Guix! [1] https://www.unisonweb.org [2] https://www.unisonweb.org/2020/04/10/reducing-churn/#definitions- getting-renamed-or-moved
Re: Questionable "cosmetic changes" commits
Hi Mark! On December 2, 2020, Mark H Weaver wrote: > We all have our own personal preferences of how best to indent scheme > code, but if more of us adopted the habit of needlessly reordering > fields and reindenting code of every package we touch, as one of us > seems to have done, it could get out of hand quickly. I don't particularly hold any opinion about stylistic commits except that I prefer tools like gofmt, Python's Black and standard.js which enforce uniform code style, and would use such a tool for my Guile code if it exists. I do think it's important to acknowledge that the commits written by Raghav were part of his internship and advised by his mentors who signed off on the commits, so it's not like these changes were unsolicited and materialized out of nowhere.
Re: npm global prefix needs to be a writeable directory
On November 26, 2020, Jelle Licht wrote: > On other distros it defaults to a location that is not writable by > normal users either; Indeed I can confirm that Ubuntu node also has this problem. > Node doesn't do this on other distros either, correct? > [snip] > Another way folks solved this problem has been using "nvm" which in > practice boiled down to [setting a > custom global prefix, just managed by nvm now]. I think Guix should work more like nvm than like other distros in this case. If this is something we could handle automatically per-profile, then that gives us the opportunity to do the right thing and save the user some hassle. If we decide not to go that route, I agree that we're doing no worse than other distros that package Node. But I'm rarely satisfied with the status quo :)
npm global prefix needs to be a writeable directory
Hi folks! I stumbled across an issue with the node package today and wanted to send a report before I forget. npm assumes that the global prefix is a writeable folder. Operations like `npm link` will fail if it isn't. Right now our node package doesn't set a prefix, so it defaults to the package's directory in the store, which isn't good. Maybe the solution is to select a folder inside the user's Guix profile (or perhaps in their XDG_CACHE_HOME, if any) and set that explicitly as the node global prefix using a profile hook. In my case, I ran `npm config set prefix /home/ryan/.cache/npm` as a workaround.
Re: /etc/passwd & co. in Docker images
On November 22, 2020, Danny Milosavljevic wrote: > Because the question is what to do if you invoke > > guix pack -f docker guix postgresql > [snip] > So I would suggest that > > guix system docker-image ... > > create /etc/passwd by merging the required user accounts like > described > above, but > > guix pack -f docker a b c > > really can't do that. This makes sense to me. If you pack just some packages, you get the binaries/libs/whatever but no supporting structure. If you pack a service or a system, you get the supporting structure to make it able to run. Then it's a matter of documenting this appropriately and making it discoverable. For example, something I want to do is set up an action in my CI that runs a Postgres db and a Rails service, then kicks off some tests. So how do I figure out what Guix command to run so that I can get Postgres and Rails into a Docker image, not just as bare minimal binaries but as services that I can actually run?
Re: /etc/passwd & co. in Docker images
On November 20, 2020, "Ludovic Courtès" wrote: > … what you’re doing here suggest that ‘guix pack’ should indeed create > those files. Oh I think it should be an option. Many Docker containers do not need those things, but it would be great to have the option to include them. Another option that would be nice, for the sake of `guix deploy` and `guix pack`, is to produce a static build. I've tried adjusting some Guix packages to produce static builds and seen dramatic reduction in bundle sizes. I've brought up those observations in IRC and from those convos I know most people aren't interested in static builds, but for deployments to a cluster, a tiny container image with a single static binary in it can be just the thing you want. This maybe plays into the "parametric packages" thread that's happening in parallel, because I could see offering this as a "static?" parameter on packages that support it.
Re: GNU Guix 1.2.0rc2 available for testing!
On November 19, 2020, Pierre Neidhardt wrote: > [--without-tests] would encourage untested builds if I > recall correctly That may have been a concern (I wasn't part of the conversation) but I don't see how the current implementation could do that. If a normal "guix build foo" fails, then it's a busted package period. I'm glad for the "without-tests" option because when I'm working on packages with a test suite that takes more than a few seconds, I like to make sure that the rest of everything is working before I start running the tests. Another thing I'd like is an option to build a package reusing the state from a previous build. If a package I'm working on takes a minute or longer to build and I'm having some sort of difficulty, it's obnoxious to wait for that to complete again after every cycle. It could be near instantaneous if I could re-use a cached build, which is doable in Docker, Earthly, and other containerized build systems.
Re: updating Jami to "Together", Qt update?
On November 18, 2020, Pierre Neidhardt wrote: > aviva writes: > > > nobody i know uses it. without a community of users, it has no > purpose > > There must always be a first user ;) I use Jami regularly with a few adventurous friends who like peer-to- peer things. We often have to fall back to another video system like Jitsi to finish our calls, but keep returning for more punishment because we believe in the dream. I have been specifically burned before by the Jami package in Guix. It hasn't played well with other Jami software; I started having better luck when I switched to using the Debian package. But if you get the Together release working well I'm absolutely down to give it another shot!
Re: Releasing guix binary in Docker format too?
On November 18, 2020, Bengt Richter wrote: > E.g., (quoted from [1]), does the following mean that the guix daemon > potentially could run "projects" > instead of guixbuilder* to create "Multiple isolated environments on a > single host" ? > The features of Compose that make it effective are: > > Multiple isolated environments on a single host > Preserve volume data when containers are created > Only recreate containers that have changed > Variables and moving a composition between environments I love docker-compose and have used it every day. There are a bunch of workflows I use compose for that I haven't figured out how to replace with Guix yet, and I'm not in a huge hurry, but it would be great to see features that are designed to appeal to Compose users. For example, a common thing I do with docker-compose is to provide a compose file with a service I'm working on that brings up the service with all its dependencies (eg databases, proxies, etc.) in a dev configuration, with the source code from the repository mapped into the container and live-reload enabled. That creates a "two-step" dev environment for the service: you clone the repo then run "docker-compose up." Hashicorp has been working on Waypoint[1], a free software tool to extend that concept even further by adding deployment and release capabilities. Now you clone a repo and you have one tool to build, deploy and release the software contained therein. I'm interested to use Guix for similar purposes, but there are a few primary obstacles in the way: 1) I don't have enough experience yet defining systems using Guix similar to what I'd define using docker-compose, and I haven't found documentation or examples yet that makes it seem within reach 2) The machines I'm deploying to run Kubernetes, not Guix System, so if I do use Guix to build a bundle for deployment its utility ends when I export to a Docker container image. 3) I collaborate with developers who use macOS and Windows and so can't easily install and use Guix. [1] https://www.waypointproject.io/
Re: Release: Docker Image? DockerHub? skopeo?
On November 17, 2020, Danny Milosavljevic wrote: > Hmm, maybe I'm misunderstanding what Docker compose does entirely. What docker-compose does is it creates a set of Docker containers for you based on a configuration file. In that file you define services, filesystem volumes and their mount points, virtual private networks, environment variables, and so on. This saves you the trouble of running a bunch of "docker run ..." commands to set up a cluster of containers. But docker-compose doesn't do anything you couldn't already do with Docker alone; it uses the Docker API to give you a more convenient interface. > Reading the docs it seems to just manage multiple isolated Docker > images and > deploy new ones? That's exactly what it does. > What then is used to do the equivalent of a guix profile with multiple > packages > in a Docker image? Something a lot of Dockers users initially think you can do, but you actually can't, is to merge two Docker images together. There's a "ruby" image and there's a "python" image but you can't just say hey Docker I want a "ruby+python" image. So there is no direct equivalent to a Guix profile with multiple packages. What you can do is start from one image, add what's needed from the other to create a new base image, and then go from there. But you have to manage that manually by running "apt" commands for Debian or "apk" for Alpine or whatever, as part of your Dockerfile build process.
Re: A plan for parameterized packages
On November 15, 2020, raingloom wrote: > Alpine already achieves an incredibly tiny install size by splitting > packages into many outputs. We could and should do the same. > As far as I know, they do not have parameterized packages. I definitely support more package-splitting and dependency tree-shaking where possible. Getting a core Guix System down to Alpine size would be fantastic. For example, `docker size python` shows a 171.4mb bundle size just for Python alone, while `docker images python:alpine` shows a 44.3mb system image, which includes a bunch of system stuff in addition to Python. It would be great to have tools to understand what's in our big Guix packages and how we could ship light bundles that get the job done.
Re: Announcing emacs-guix-packaging
On November 12, 2020, "Ludovic Courtès" wrote: > Looks nice and useful! Thank you! If you end up using it, I'd be interested to hear feedback about what works well and what could go in a different direction. > Did you consider making it part of Emacs-Guix? That’d give us a single > go-to place for all things Guix in Emacs. I don't use emacs-guix myself. I've tried it a couple times but it's junky. Specifically, it incorporates a lot of custom Guile logic and depends on internal Guix APIs. This design does not benefit anybody. It's harmful for the Guix project because having third-party applications depend on your internal APIs locks you down, where you can't refactor internal logic without breaking other people's stuff. And it's sad for users because it exposes them to that routine brokenness, which in my case has prevented me from ever getting any use out of it when I've tried it. And I know I'm not just unlucky: at least once a month we get people in the IRC or Matrix rooms for Guix who are unable to make emacs-guix work on their machines. For an interface to Guix, which aims to solve software deployment problems, this is especially cringe-inducing. It shows the fundamental weakness of the package's technical design. So as a result I'm not really interested in contributing to emacs-guix. I would of course not object if its maintainer wanted to incorporate parts of my package into theirs. They are both GPLv3. On the other hand, I am interested in building out a formal API for tools to interface with Guix without having to depend on its internals or parse the output of its CLI commands. This could be a Guile API, although I picture json would be a better choice to support diverse tooling. For one example of what I'd want the API for, in my `guix-packaging- insert-input` command I need to get the list of available Guix packages, and then for the selected package I need to find its scheme symbol. The emacs-guix approach to those things is to reach into Guix internal data structures and read out that data, which doesn't deliver results in practice. I opt instead to parse the output of the CLI command `guix package -A ""` as a tsv, which works as long as Guix doesn't change its output, but that's not guaranteed either. The format of the output from Guix CLI commands varies quite a lot. After parsing the tsv from one command, the next step is to find the corresponding scheme symbol for the chosen package, for which I parse the output of `guix show ` but that's not tsv, that's recfile format. And it doesn't provide the name of the scheme symbol, so I then go load the source code and look for a `define-public` to scrape the symbol. So what I'd want is a uniform scripting interface where I can query Guix and get responses in a uniform way, whether that's json, recfile, edn, msgpack, or Guile s-expressions or whatever. Just so it's an explicitly documented external API that won't change arbitrarily, doesn't freeze Guix internals, and only requires me to parse one type of output. At some point in the future I can write more about that, and I'm down to contribute the labor to make it happen too. We can use this thread as a kick-off point for that discussion too if you're interested. But in any case I just wanted to provide some context for why I didn't build this as an extension to emacs-guix. Hope this helps! Ryan
Re: Latest Nyxt features a GUI for Guix :)
On November 11, 2020, Jan Wielkiewicz wrote: > [web browsers are] a really poorly designed copy of > operating systems and its utilities. > > [...] > > I just don't understand why in the web browser. > I'll try it. The web browser is the primary operating environment for a lot of people. Just as Emacs users built web browsers, terminal emulators, and mail clients on the Emacs platform, the web platform also has all those things (including various elaborate in-browser code editors.) So I understand this as having the exact same genesis as the Guix interface in Emacs: people would like to manage their operating system using the interface they spend most of their time in, and for Nyxt power users that would be their browser. I'm not at all interested in managing my Guix packages using Nyxt, which is highly correlated to my not being a Nyxt power user.
Announcing emacs-guix-packaging
Hi folks! I use Emacs to write and maintain Guix packages, and I've created some tools and snippets to automate repetitive tasks and remove guesswork. If you also use Emacs, you might be interested to try them or contribute your own. My repository is here: https://github.com/ryanprior/emacs-guix-packaging To read the elisp file without any non-free JavaScript, use this link: https://raw.githubusercontent.com/ryanprior/emacs-guix- packaging/main/guix-packaging.el I'm calling this my 1.0 release. It's got commands that I'm using daily, some slick snippet-based workflows for packaging go modules (what I've been doing a lot of lately,) and documentation. I will continue to update it and I welcome your feedback and ideas! I don't have a release on GNU ELPA or Guix yet. Despite helping maintain a few Emacs packages for some years, this is the first package I've created myself and set up the infrastructure for, so I'm still figuring those things out. Cheers
