On 05/07/15 17:33, Mark H Weaver wrote:
Normally I use more whitespace, but in this case I think it's perfectly
readable. What do you think?
Sure.
The tab issues were caused by my using the scheme mode of emacs rather
than the guile one, and shouldn't happen any more. Apparently also when
yo
Ben Woodcroft writes:
> From d220bdeac89660108de96a96107daf89182310e0 Mon Sep 17 00:00:00 2001
> From: Ben Woodcroft
> Date: Wed, 24 Jun 2015 14:32:26 +1000
> Subject: [PATCH] gnu: Add yaggo.
>
> * gnu/packages/ruby.scm (yaggo): New variable.
> ---
> gnu/packages/ruby.scm | 32 +
To be clear (to avoid me being pigeon holed as the guy who wants
something that is not pure), we all agree on the following: We agree
to allow people to use bundler and gems if they want to. We agree that
gems can be packaged in Guix (as long as there is no binary code). And
we agree that we should
Thompson, David writes:
> This will work against our goals. It will create a lot of duplicated
> files which will eat up extra disk space and make it difficult to
> apply security patches. The job of a distribution is to deduplicate,
> not bundle. Furthermore, it will cover up the lack of su
On Wed, Jun 24, 2015 at 3:23 PM, Pjotr Prins wrote:
> On Wed, Jun 24, 2015 at 08:32:51AM -0400, Thompson, David wrote:
>> I don't know about $GEM_SPEC_CACHE, but $GEM_HOME cannot be a native
>> search path that is part of our ruby packages, because native search
>> paths are relative to store item
On Wed, Jun 24, 2015 at 7:41 PM, Ben Woodcroft wrote:
>
>
> On 24/06/15 22:19, Thompson, David wrote:
>>
>> Perhaps ruby should
>> be a propagated input for packages with ruby executables, or scripts
>> could be wrapped in another script that set the correct environment
>> variables.
>
> A naive q
On 24/06/15 22:19, Thompson, David wrote:
Perhaps ruby should
be a propagated input for packages with ruby executables, or scripts
could be wrapped in another script that set the correct environment
variables.
A naive question - I don't believe that this is required for e.g. python
packages th
On Wed, Jun 24, 2015 at 08:32:51AM -0400, Thompson, David wrote:
> I don't know about $GEM_SPEC_CACHE, but $GEM_HOME cannot be a native
> search path that is part of our ruby packages, because native search
> paths are relative to store items, which are immutable. My feeling is
> that if the user
> I must reiterate my concern about this approach to the wider
> guix-devel audience. From what I can see, the gem archives hosted on
> rubygems.org are build artifacts and should probably be treated like
> pre-built binaries. They are not the complete, corresponding source
> code. Can anyone e
On Wed, Jun 24, 2015 at 1:51 AM, Pjotr Prins wrote:
> On Wed, Jun 24, 2015 at 02:35:03PM +1000, Ben Woodcroft wrote:
>> Actually, I lie, this patch only sort of works. The issue is that it
>> only works when a ruby package is also installed, GEM_PATH does not
>> get set as part of the ruby-build-s
On Wed, Jun 24, 2015 at 12:35 AM, Ben Woodcroft wrote:
> Actually, I lie, this patch only sort of works. The issue is that it only
> works when a ruby package is also installed, GEM_PATH does not get set as
> part of the ruby-build-system for yaggo. The lib/ files are copied to what I
> gather is
On Wed, Jun 24, 2015 at 02:35:03PM +1000, Ben Woodcroft wrote:
> Actually, I lie, this patch only sort of works. The issue is that it
> only works when a ruby package is also installed, GEM_PATH does not
> get set as part of the ruby-build-system for yaggo. The lib/ files
> are copied to what I gat
Actually, I lie, this patch only sort of works. The issue is that it
only works when a ruby package is also installed, GEM_PATH does not get
set as part of the ruby-build-system for yaggo. The lib/ files are
copied to what I gather is the correct place, but the env isn't right.
The same also a
13 matches
Mail list logo
