all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de>
To: Ben Woodcroft <b.woodcroft@uq.edu.au>
Cc: "guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: Re: [PATCH] Gemspecs / Add ruby-ruby-engine.
Date: Tue, 5 Jan 2016 15:47:28 +0100	[thread overview]
Message-ID: <idjpoxggk1r.fsf@bimsb-sys02.mdc-berlin.net> (raw)
In-Reply-To: <568BB25E.3040805@uq.edu.au>


Ben Woodcroft <b.woodcroft@uq.edu.au> writes:

> On 05/01/16 21:36, Ricardo Wurmus wrote:
>> Ben Woodcroft <b.woodcroft@uq.edu.au> writes:
> [..]
>>> While I managed to install 1.0.1, I wasn't sure how best to remove the
>>> 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 are
>>> 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 “build” phase in the “ruby-build-system” is responsible for
>> rebuilding the gem from source.  The “unpack” phase unpacks the gem
>> archive.  This should allow you to modify the gemspec in a phase
>> injected between “unpack” and “build”, no?
>
> That's not what I'm getting from reading of the code, no. The build 
> phase of the ruby build system unpacks the gemspec from the source .gem 
> 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 “unpack” phase,
or as you suggest during an additional “gemspec” 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’d have to make sure 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 
> 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 “unpack” instead?  It’s just a
>> side-effect of the “check” phase that the gem is installed, so I think
>> it’s best to move this phase right after “unpack” (because we don’t need
>> any of this stuff for any of the phases until “check”).
>>
>> Maybe you can also add a FIXME comment (as in “ruby-pygmentize”) stating
>> that this really should be done in a snippet.
> Unfortunately we cannot move it since the build phase will then fail for 
> the above reason.

True.

>> Please keep this on one line.
>> Otherwise it’s fine.  Thank you!
> No problem. I'm happy to send a follow up patch if you like, but would 
> prefer to resolve the larger problem first.

Agreed.  I’d be happy if someone else could chime in to give an opinion
on whether to add a new phase or merge gemspec extraction with “unpack”.

~~ Ricardo

  reply	other threads:[~2016-01-05 14:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-30  7:13 [PATCH] Gemspecs / Add ruby-ruby-engine Ben Woodcroft
2016-01-05 11:36 ` Ricardo Wurmus
2016-01-05 12:09   ` Ben Woodcroft
2016-01-05 14:47     ` Ricardo Wurmus [this message]
2016-01-05 16:53       ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=idjpoxggk1r.fsf@bimsb-sys02.mdc-berlin.net \
    --to=ricardo.wurmus@mdc-berlin.de \
    --cc=b.woodcroft@uq.edu.au \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.