GNU bug report logs - #44882
[PATCH] gnu: ruby-solargraph: Update to 0.39.17 and add two dependencies

Previous Next

Package: guix-patches;

Reported by: Tomás Ortín Fernández <tomasortin <at> mailbox.org>

Date: Thu, 26 Nov 2020 10:03:01 UTC

Severity: normal

Tags: patch

Done: Björn Höfling <bjoern.hoefling <at> bjoernhoefling.de>

Bug is archived. No further changes may be made.

Full log


Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Tomás Ortín Fernández via Guix-patches via
 <guix-patches <at> gnu.org>
Cc: 44882 <at> debbugs.gnu.org
Subject: Re: [bug#44882] Dependencies issues
Date: Fri, 4 Dec 2020 14:56:14 -0500
On Sat, Nov 28, 2020 at 09:53:20AM +0100, Tomás Ortín Fernández via Guix-patches via wrote:
> I have realized this patch isn't correct. I hadn't tested it on a clean environment before.
> Solargraph requires Rubocop 0.52 (!). In fact, the current version of Solargraph doesn't currently work, either: there are version issues with Rubocop and with ruby-thor.

Okay, thanks for the followup email.

> I need a more-or-less current Solargraph and Rubocop, that's why I have been updating some packages, but I realize now I wasn't doing it properly and that I'm getting tangled into a web of dependencies issues.
> 
> How should I proceed? Clearly Rubocop should be updated, but I don't know how to keep Solargraph working and how to figure out which packages will need to be updated or checked in case they need an older version of Rubocop.

It's not clear to me exactly what is wrong, so I can't give specific
advice. If Solargraph is not currently working, you don't need to "keep
it working" while doing other work, right?

To check what packages will be rebuilt if the Rubocop package changes,
you can use `guix refresh --list-dependents ruby-rubocop`. Building and
testing the packages listed by that command will allow you to test the
impact of any changes to ruby-rubocop.

Currently, our ruby-rubocop package is at version 0.88.0. We don't
usually downgrade packages, but you can add another package based on the
earlier version 0.52. For example, something like this (untested!):

------
(define-public ruby-rubocop-0.52
  (package
    (inherit ruby-rubocop)
    (version "0.52")
    (source (origin [...]))))
------

... then use ruby-rubocop-0.52 as an input to the Solargraph package.

In general, dealing with complex dependency graphs while updating
packages is hard, but Guix makes it easier. I would start at the top of
the graph: try building the new Solargraph, see which dependencies are
too old, update them, repeat. Once Solargraph is working, you can use
`guix refresh --list-dependents` for each changed package, fix any
breakage, and so on.

Does that make sense? Please don't hesitate to keep asking for advice,
here or on our Freenode IRC channel #guix




This bug report was last modified 4 years and 84 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.