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
next prev parent 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
List information: https://guix.gnu.org/
* 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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).