Re: How to move forward about Rust? antioxidant, cargo2guix, etc.

I made a follow-up on fediverse: https://social.boiledscript.com/notes/a4kcjwcgon In short: Package crates as origins, limit them in one module, so there won't be variables duplicated within one Guix channel. Every Guix channel can have their own such file to avoid API breakage, since origins p

Re: diff-wiggle missing wiggle in Emacs

Hi Christopher, jgart, Christopher Howard writes: "jgart" writes: Hi guixers, Should we include wiggle as a dependency of Emacs since it is used by the diff-wiggle function from diff-mode.el? For my part — an enthusiastic Emacs user — I'd be a little hesitant to go down the path of a

Re: How to move forward about Rust? antioxidant, cargo2guix, etc.

On Sun, Feb 23, 2025 at 04:48:10PM +0100, Ludovic Courtès wrote: > Hi, > > Efraim Flashner skribis: > > > I would like to get away from the cargo-inputs and > > cargo-development-inputs if possible and to have all the packages as > > regular and native inputs. > > This is what I looked at in

Re: "guix package -u automake" pulls in gtk

Andreas Enge writes: > Am Sun, Feb 23, 2025 at 06:21:27PM +0100 schrieb Ricardo Wurmus: >> > I also encounter the failure below in python-uvicorn, which is a >> > prerequisite for rest. >> This may be a non-deterministic failure. It built fine on my laptop. > > Unless you have an ARM laptop, whi

Re: "guix package -u automake" pulls in gtk

Andreas Enge writes: > Am Sun, Feb 23, 2025 at 06:21:27PM +0100 schrieb Ricardo Wurmus: >> > I also encounter the failure below in python-uvicorn, which is a >> > prerequisite for rest. >> This may be a non-deterministic failure. It built fine on my laptop. > > Unless you have an ARM laptop, whi

Importer (specifically rust/crates) Packaging Workflow?

Hello Guix, What is your workflow for adding packages via `guix import` which have a lot of new/updated dependencies? Though `guix import` almost always writes the package defs perfectly, I find the real tedium is _placing_ all of these imported packages in their proper places... it becomes loo

Re: guix build -P not building dependent(s) of django package

Hello, Am Sun, Feb 23, 2025 at 04:30:34PM +0100 schrieb Ludovic Courtès: > So you can run: > guix build --dependents python-django-cache-url > or: > guix build -P1 python-django-cache-url that "--dependents" and "-P" behave differently is somewhat confusing and not really explained in the doc

Re: Users of demlo package.

Am Sun, Feb 23, 2025 at 07:03:46PM -0800 schrieb Felix Lechner: > As a general matter, I'd just drop it. The package is easy to re-add > later, if needed. This is always the case for leaf packages. Since we have a removal policy, we should follow it. (Well, I am aware of a mild contradiction, sin

Re: Mumi list interface [Was: mumi CLI now supports tagging]

Hi Felix, > I find that the list interface [1] made the website [2] less helpful, Could you please elaborate? Maybe we can work out the shortcomings of the new interface. Regards, Arun

Re: example of poor debugging message (follow up Guix Days)

On 2025-02-24 13:29, 45mg wrote: But with Guile, even the function names and arguments are mostly replaced with underscores, so the backtrace tells me almost nothing. I'd have to manually open every single file location in the stack to find out the function names. As for the arguments, I'd actual

Re: example of poor debugging message (follow up Guix Days)

45mg <45mg.wri...@gmail.com> writes: > Jokes aside, it would be nice to find out why the location of the > package definition isn't displayed in the backtrace. But I feel like I'd > need a very thorough understanding of how `guix build` works to figure > it out. One important complication to keep

Re: example of poor debugging message (follow up Guix Days)

Hi, On Mon, Feb 24 2025, Ricardo Wurmus wrote: > - it's not always just down to Guile's poor backtraces (which on their own > can be puzzling, no question about it) > - on the compilation side of things I think Guix would benefit from > enforcing type contracts to trigger errors earlier. Tho

Re: guix build -P not building dependent(s) of django package

> > Build the dependents of the following package. With @code{-P}, > the @var{depth} argument is mandatory and limits to dependents at that > distance: 1 for direct dependents, 2 for dependents of dependents, > and so on. With @code{--dependents}, the @var{depth} argument is > Hi, The flags are

Re: How to move forward about Rust? antioxidant, cargo2guix, etc.

Hi Simon, thanks for bringing up the discussion again. On Fri Feb 21, 2025 at 11:23 AM -03, Simon Tournier wrote: > How does it compare with antioxidant? And your (Nicolas) ideas? Antioxidant and Nicolas proposal is for a new build system (rust-build-system) in Guix best aligned with we already

Re: How to move forward about Rust? antioxidant, cargo2guix, etc.

Hi Murilo, On Mon, Feb 24 2025, Murilo wrote: > generating guix package definitions from Cargo.lock. How else can we avoid packaging errors like this one? [1] Kind regards Felix P.S. I'm not a Rust person & behind on the conversation. [1] https://issues.guix.gnu.org/76444

Re: How to move forward about Rust? antioxidant, cargo2guix, etc.

On Mon, Feb 24, 2025 at 12:51:02PM -0300, Murilo wrote: > Hi Simon, thanks for bringing up the discussion again. > > On Fri Feb 21, 2025 at 11:23 AM -03, Simon Tournier wrote: > > How does it compare with antioxidant? And your (Nicolas) ideas? > > Antioxidant and Nicolas proposal is for a new bu

Re: How to move forward about Rust? antioxidant, cargo2guix, etc.

On Mon, Feb 24, 2025 at 08:35:13AM -0800, Felix Lechner wrote: > Hi Murilo, > > On Mon, Feb 24 2025, Murilo wrote: > > > generating guix package definitions from Cargo.lock. > > How else can we avoid packaging errors like this one? [1] > > Kind regards > Felix > > P.S. I'm not a Rust person &

Re: diff-wiggle missing wiggle in Emacs

"jgart" writes: > Hi guixers, > > Should we include wiggle as a dependency of Emacs since it is used by the > diff-wiggle function from diff-mode.el? > For my part — an enthusiastic Emacs user — I'd be a little hesitant to go down the path of adding explicit package dependencies for runtime re