From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: [PATCH] Gemspecs / Add ruby-ruby-engine. Date: Tue, 5 Jan 2016 15:47:28 +0100 Message-ID: References: <5683842C.3090706@uq.edu.au> <568BB25E.3040805@uq.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:58991) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGSth-0001Kl-QT for guix-devel@gnu.org; Tue, 05 Jan 2016 09:47:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aGStc-0001Nr-Pa for guix-devel@gnu.org; Tue, 05 Jan 2016 09:47:41 -0500 Received: from venus.bbbm.mdc-berlin.de ([141.80.25.30]:32999) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGStc-0001NE-Ct for guix-devel@gnu.org; Tue, 05 Jan 2016 09:47:36 -0500 In-Reply-To: <568BB25E.3040805@uq.edu.au> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ben Woodcroft Cc: "guix-devel@gnu.org" Ben Woodcroft writes: > On 05/01/16 21:36, Ricardo Wurmus wrote: >> Ben Woodcroft writes: > [..] >>> While I managed to install 1.0.1, I wasn't sure how best to remove th= e >>> bundled 1.0.0 .gem file. The issue is that when the source is a .gem >>> file (ie most of the time), the gemspec is taken from the downloaded >>> .gem file directly, and in the same phase the .gem file is built. So = as >>> a packager there is no way to make changes to the gemspec without >>> replacing the entire build phase. There's a number of rubygems that a= re >>> contaminated with junk so it would be great for there to be a simple = way >>> to modify the gemspec before "gem build" is run. >> The =E2=80=9Cbuild=E2=80=9D phase in the =E2=80=9Cruby-build-system=E2= =80=9D is responsible for >> rebuilding the gem from source. The =E2=80=9Cunpack=E2=80=9D phase un= packs the gem >> archive. This should allow you to modify the gemspec in a phase >> injected between =E2=80=9Cunpack=E2=80=9D and =E2=80=9Cbuild=E2=80=9D,= no? > > That's not what I'm getting from reading of the code, no. The build=20 > phase of the ruby build system unpacks the gemspec from the source .gem= =20 > file and then immediately uses it to build the gem. Oh, you are right! The gemspec file is deleted if it exists and then extracted from the source gem. Sorry, I should have looked at the code more carefully. I think extracting the gemspec should be done during the =E2=80=9Cunpack=E2= =80=9D phase, or as you suggest during an additional =E2=80=9Cgemspec=E2=80=9D phase. But how does this relate to snippets? In other build systems snippets cause the source archive to be unpacked, modified, and then repacked. If we split unpacking and gemspec extraction we=E2=80=99d have to make su= re that this also works when snippets are involved, i.e. snippets should see the extracted gemspec (as the original one is discarded by the build system anyway). > It is fine to remove the offending files but the gemspec must be=20 > modified accordingly otherwise "gem build" fails. You are right. >>> + (arguments >>> + `(#:phases >>> + (modify-phases %standard-phases >>> + (add-before 'check 'clean-up >> Is it possible to move this after =E2=80=9Cunpack=E2=80=9D instead? I= t=E2=80=99s just a >> side-effect of the =E2=80=9Ccheck=E2=80=9D phase that the gem is insta= lled, so I think >> it=E2=80=99s best to move this phase right after =E2=80=9Cunpack=E2=80= =9D (because we don=E2=80=99t need >> any of this stuff for any of the phases until =E2=80=9Ccheck=E2=80=9D)= . >> >> Maybe you can also add a FIXME comment (as in =E2=80=9Cruby-pygmentize= =E2=80=9D) stating >> that this really should be done in a snippet. > Unfortunately we cannot move it since the build phase will then fail fo= r=20 > the above reason. True. >> Please keep this on one line. >> Otherwise it=E2=80=99s fine. Thank you! > No problem. I'm happy to send a follow up patch if you like, but would=20 > prefer to resolve the larger problem first. Agreed. I=E2=80=99d be happy if someone else could chime in to give an o= pinion on whether to add a new phase or merge gemspec extraction with =E2=80=9Cu= npack=E2=80=9D. ~~ Ricardo