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: "Thompson, David" <dthompson2@worcester.edu>
Cc: "guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: Re: [PATCH] Add yaggo.
Date: Wed, 24 Jun 2015 15:05:26 +0200	[thread overview]
Message-ID: <idjfv5hntnt.fsf@bimsb-sys02.mdc-berlin.net> (raw)
In-Reply-To: <CAJ=RwfbF7Yg0+cVOTzTYhbqEPFdnQujh0VsXKY8Q0egSKDUt5A@mail.gmail.com>


> 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 else weigh in here?

The gemspec file must list all files (either explicitly or via patterns)
that are to be distributed and thus needed at runtime.

As far as I can tell "gem push name.gem" can be used to upload anything
to rubygems.org that is considered a valid gem.  rubygems.org will only
extract the gemspec metadata and process them for later display[1].  The
parsed and possibly validated gemspecs are included in the gem when
doing "gem build name.gemspec".  For more info on what "gem build" does
see [2].

This means that using standard tools (unmodified "gem") the generated
gem is packaged according to the information in the gemspec file.  A gem
seems to be little more than a tar archive.  I would not consider this a
"build artifact", but release tarballs.  We don't have a problem with
using release tarballs over git clones for non-Ruby applications, even
though the tarballs may contain somewhat different sources (e.g. added
ChangeLog).

Of course, a gem created with a modified tool could contain more or less
than what the gemspec file declares.  But I would treat this in much the
same manner as I would treat broken release tarballs.

~~ Ricardo

[1]: https://github.com/rubygems/rubygems.org/blob/master/app/models/pusher.rb#L47
[2]: https://github.com/rubygems/rubygems/blob/master/lib/rubygems/package.rb

  reply	other threads:[~2015-06-24 13:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-24  4:35 [PATCH] Add yaggo Ben Woodcroft
2015-06-24  5:51 ` Pjotr Prins
2015-06-24 12:32   ` Thompson, David
2015-06-24 13:05     ` Ricardo Wurmus [this message]
2015-06-24 19:23     ` Pjotr Prins
2015-06-25 22:47       ` Thompson, David
2015-06-26  6:56         ` Ricardo Wurmus
2015-06-26  7:40           ` Pjotr Prins
2015-06-24 12:19 ` Thompson, David
2015-06-24 23:41   ` Ben Woodcroft
2015-06-25 22:25     ` Thompson, David
2015-07-05  7:33 ` Mark H Weaver
2015-07-05 11:33   ` Ben Woodcroft

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=idjfv5hntnt.fsf@bimsb-sys02.mdc-berlin.net \
    --to=ricardo.wurmus@mdc-berlin.de \
    --cc=dthompson2@worcester.edu \
    --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.