Re: Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works)

Hi Ryan, Thank you for your detailed explanations. Here I try to connect the dots between the current blocks and the picture you are drawing. On Sat, 19 Mar 2022 at 18:18, Ryan Prior wrote: > When I install Docker for Desktop on macOS or Windows, I do not have > to first install a VM manager

Re: Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works)

Zhu Zihao writes: > Make Guix available on Windows platform will be a painful job. > > 1. Windows doesn't allow user to create symbolic link without admin > permission, which guix use intensely. > > 2. There's no RUNPATH for Windows DLL, so all dynamic library > dependencies should in the same

Re: Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works)

Hello everyone, Just a small comment stemming from my time fiddling with Win32 API and friends. Zhu Zihao writes: > 2. There's no RUNPATH for Windows DLL, so all dynamic library > dependencies should in the same directory to allow Windows find it. There actually is an analogue for RUNPATH, beca

Re: Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works)

Make Guix available on Windows platform will be a painful job. 1. Windows doesn't allow user to create symbolic link without admin permission, which guix use intensely. 2. There's no RUNPATH for Windows DLL, so all dynamic library dependencies should in the same directory to allow Windows find i

Re: Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works)

This is heading in the right direction - in my analysis, many things we do, including Free Software, are all forms of creative subversion of Capitalism. We need note creativity, not less 😄 > On Mar 20, 2022, at 03:19, Ryan Prior wrote: > > Zimoun wrote: >> Today, Guix provides a script that

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 th

Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works)

Hi, > 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-

Re: Fetching sources using Guix (re: Building a software toolchain that works)

Hi Ryan, March 19, 2022 1:08 AM, "Ryan Prior" wrote: > 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 shoul

Re: Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works)

Hi Ryan, Perhaps Im being cynical but opening the doorway to lots of plug-and-play users atm could overwhelm the people heroically stabilising and smoothing out the OS. Jonathan March 19, 2022 1:21 AM, "Ryan Prior" mailto:rpr...@protonmail.com?to=%22Ryan%20Prior%22%20)> wrote: One side-thread

Re: Guix as a system vs as an end-user dev tool (re: Building a software toolchain that works)

Hi, Am Samstag, dem 19.03.2022 um 00:20 + schrieb Ryan Prior: > 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. That's true to

Re: Fetching sources using Guix (re: Building a software toolchain that works)

Ryan Prior schreef op za 19-03-2022 om 00:08 [+]: > 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 th

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

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 packag

Re: Building a software toolchain that works

Hello David, I am huge fan of Guix on WSL2 and I used to use it a lot 😄. And yes, it should be documented well (or even better, the installation should be made super simple) while as you mentioned, it might be easier to do this in another community. I don't share the ideology of hardline reje

Re: Building a software toolchain that works

On 2022-03-17 13:56, zimoun wrote: Hi Olivier, On another note, what I find fascinating is why Guix and Nix are not more used in academic papers. Indeed. One part of the answer is, IMHO: it is difficult to spread the word. For instance, with co-authors, we have tried to write a short paper

Re: Building a software toolchain that works

On 2022-03-18 07:27, Pjotr Prins wrote: On Thu, Mar 17, 2022 at 03:04:18PM -0500, Katherine Cox-Buday wrote: In addition, because free software is largely developed in people's spare time, they're going to use whatever tools make them most productive or even just happy. They're probably not thi

Re: Building a software toolchain that works

On Thu, Mar 17, 2022 at 03:04:18PM -0500, Katherine Cox-Buday wrote: > In addition, because free software is largely developed in people's spare > time, they're going to use whatever tools make them most productive or even > just happy. They're probably not thinking about their software against t

Re: Building a software toolchain that works

I run Guix everywhere I can, and it's now the only way I develop software. Having said that, I have thought about this issue a little bit, and here's my opinion on why this happens. Pjotr Prins writes: > And they start out as the next new thing to solve all problems! If > they would only woul

Re: Building a software toolchain that works

On Thu, Mar 17, 2022, at 11:35, Maxime Devos wrote: > Why skip downstream patches and snippets? The spirit of the workflow is to enable someone to easily contribute a patch to an upstream project. With that in mind, I assumed that our downstream patches would not be accepted by the upstream projec

Re: Building a software toolchain that works

David Arroyo schreef op ma 14-03-2022 om 17:40 [-0400]: > 1. Obtain the source and unpack it into a writable working directory, >    skipping downstream patches and snippets. Why skip downstream patches and snippets? Often, these are necessry to make the source actually compileable (e.g. if it us

Re: Building a software toolchain that works

Hi Olivier, > On another note, what I find fascinating is why Guix and Nix are not > more used in academic papers. Indeed. One part of the answer is, IMHO: it is difficult to spread the word. For instance, with co-authors, we have tried to write a short paper detailing what Guix solves, i.e., t

Re: Building a software toolchain that works

Hi Ryan, > 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. Do not miss:

Re: Building a software toolchain that works

Hi, On Tue, 15 Mar 2022 at 09:19:50 +0100, Ludovic Courtès wrote: > > One could develop a `guix contribute ` subcommand or standalone > > script that would implement the following workflow: > > > > 1. Obtain the source and unpack it into a writable working directory, > >skipping downstream p

Re: Building a software toolchain that works

I am very interested in this topic, too! At work, I have been forced to use the NPM package manager and since the first day I have been unable to understand this enigma - how on earth do people work with this fuzzy system almost designed to be unaccountable?? Can Guix replace NPM? I think we

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 softwar

Re: Building a software toolchain that works

Hello everyone, Let me chime in on a specific point. "David Arroyo" writes: > I recently used guix to make a one-line change to the dovecot-pigeonhole > package. Initially I tried to do this without guix, and had difficulties > using autoconf/automake. So instead, I made my changes, captured the

Re: Building a software toolchain that works

Hi, I posted something similar recently but I know there are 100s of banks and hedge funds alike that run daily calculations on arrays of servers , and they have very tricky changes in both software and data, daily. Do you think Guix(HPC - i don't know what specializations go there 😅) can be t

Re: Building a software toolchain that works

On Tue, Mar 15, 2022 at 09:23:33AM +0100, Ludovic Courtès wrote: > This is what we’re pushing as part of the Guix-HPC effort¹. Ricardo’s > research team, for instance, has published bioinfo papers that build on > Guix for reproducibility. Colleagues of mine in HPC (linear algebra and > run-time s

Re: Building a software toolchain that works

Hi! Olivier Dion via "Development of GNU Guix and the GNU System distribution." skribis: > On another note, what I find fascinating is why Guix and Nix are not > more used in academic papers. A quick search on the Compendex database > gives me only a handful of papers referencing Guix, mostly a

Re: Building a software toolchain that works

Hi, "David Arroyo" skribis: > One could develop a `guix contribute ` subcommand or standalone > script that would implement the following workflow: > > 1. Obtain the source and unpack it into a writable working directory, >skipping downstream patches and snippets. > 2. Drop the user into a s

Re: Building a software toolchain that works

On Mon, 14 Mar 2022, Pjotr Prins wrote: > I can't believe that mess that is Rust cargo and npm packages today, > for example. And they start out as the next new thing to solve all > problems! If they would only would have used Guix to create a coherent > build system... > > And then I spent a we

Re: Building a software toolchain that works

A snapshot of the guix repository is similar to a snapshot of Google's "google3" monorepo. It differs, in that rather than containing the full source of a specific version of every software package, it encodes instructions on how to obtain and build a specific version of each package. This has some

Re: Building a software toolchain that works

On Mon, Mar 14, 2022 at 07:05:30PM +, Ryan Prior wrote: >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 wa