guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add yaggo.


From: Ricardo Wurmus
Subject: Re: [PATCH] Add yaggo.
Date: Fri, 26 Jun 2015 08:56:03 +0200

Thompson, David <address@hidden> 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 such packages
> in Guix and discourage people from packaging them.  Instead, we could
> make a 'guix import rubygems' program that generates all the necessary
> package boilerplate for the requested package and for the missing
> dependencies.

I agree with David that an importer for gems is the way to go here.  The
importer for Python has greatly simplified the process of writing
package definitions and for Ruby modules it should have a similar
effect.

We cannot let the perceived additional convenience of bundling stuff
override the underlying principles of functional package management with
Guix.  This may not be the fastest approach as it takes time to package
dependencies and untangle and break dependency cycles, but it is better
than needlessly bundling “binaries”.

> Ricardo's response earlier in the thread has given me some confidence
> that the gem archives on rubygems.org do qualify as the corresponding
> source code.  That said, we really cannot use pre-built software under
> any circumstances, because it compromises the project's goals of
> reproducibility and the ethics of free software.

+1

>> Making it hard(er) to install gems from GNU Guix for normal users will
>> only slow down adoption. Allow using rubygems for those gems that are
>> not (yet) supported by us. When enough Ruby people move to using Guix
>> for their development we may get rid of rubygems altogether. I would
>> love that. I already got rid of rvm :)
>
> I'm not advocating that we prevent users from using 'gem'.  Right now,
> it is possible for users to 'gem install bundler' and build Ruby
> applications as they typically would.  I have done so on my GuixSD
> machine.  So, let's package things the right way and let people just
> use 'bundler' if they want some other stuff.

I agree.  As long as the original method of using ‘gem’ and ‘bundler’
still works I don’t see any need for compromises.  It’s not like we’re
facing a technical problem we cannot solve.  It’s just that we haven’t
packaged a lot of Ruby stuff yet; same goes for Java stuff where the
same reasoning applies.

>> Nix experimented by converting all gems to Nix packages, that is
>> another possibility. But I think they proved it is hard and now
>> defunct (correct me if I am wrong).
>
> We of course wouldn't just auto-generate *everything* and dump it in
> the repo.  There's still the human work of inspecting licenses,
> writing synopses and descriptions, adding unspecified dependencies
> (happens a lot), etc.

And that’s where an importer would be very helpful, so that humans only
have to check and modify rather than write everything from scratch.

~~ Ricardo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]