[Rubygems-developers] extensions fall back option

Trans transfire at gmail.com
Sat Nov 10 15:27:11 EST 2007


On Nov 10, 2007 2:26 PM, Luis Lavena <luislavena at gmail.com> wrote:
> On Nov 10, 2007 8:05 AM, Trans <transfire at gmail.com> wrote:
> > On Nov 9, 2007 11:12 PM, Luis Lavena <luislavena at gmail.com> wrote:
> > >
> > > I guess that will work... but must validate my idea later (with a
> > > windows machine handy) :)
> >
> > If you read my prior poists, you would know that's exactly what I did
> > with the current TMail gem. And in no uncertain terms it is a complete
> > *hack*. Nor is it a perfect solution. If nmake or make is not present
> > it still bombs.
> >
>
> I was lazy enough to look the previous post of this thread, sorry :-)

I cam across a bit hard. I just wanted to let you know that I put a
solution out for that a few posts back. But it was in separate thread:

  pure-ruby vs. compile-on-intsall

> > I would like to know the RubyGems official policy on supporting a
> > pure-ruby version of a library that can also have platform extensions.
> > As far as I can tell,  there is no clear policy for this.
>
> I see this somehow different:
>
> <gemname> is marked ::RUBY platform, and don't bundle the native
> extension (because it can run without it).
>
> <gemname>_native or _c or _extension is just the extension compiled
> for the platform, or marked ::RUBY to fire the compile process.
>
> in <gemname> you try rescue the presence of 'gemname_native', and also
> add that in the summary of the gem:
>
> "add gemname_native to get a boost of performance in your platform --
> remember that you need a compiler in case no pre-built gem is
> available".
>
> Making this clear to the end-user will reduce the questions about it.
> Still, there are gems that cannot revert to pure-ruby solution for the
> missing extension, and is good they fail if no compiler is available.
>
> Trans, these are my POV of the situation, and I'm not trying to
> convince you is the right way of doing it :-)

I considered this approach. I thought:

   tmail-1.1.1.gem
   tmail_fast-1.1.1.gem

But when someone depends on this library which do they choose? Do they
choose the slow which they know will work, or the fast one which may
not work? Clearly for the end-user I want them to have the fast one IF
the compile works, and  the slow otherwise. So maybe better:

   tmail-1.1.1.gem
   tmail_ruby-1.1.1.gem

So then depend on tmail, and I could hack in a warning that
compilation failed, and they can install tmail_ruby instead if they
want. That's pretty good. But one of my jobs as a programmer is to
make my end-users life as easy as possible, so why not have it
complete installation without the extension if I set that option in
the gemspec telling it that it is okay to do so, and just tell the end
user it installed but without native extension.

Think also of it this way. tmail-1.1.1.gem is going to contain almost
the exact same files as tmail_ruby-1.1.1.gem, minus perhaps the ext/
source code. So why clutter up Rubyforge with two copies of every
release when one would do? PLUS, what if someone installed both tmail
and tmail_ruby? Probably it will be okay, but it might be dishing out
files from two separate locations, so it might not. And finally what
about

  gem tmail

vs.

  gem tmail_ruby

Might this not force my users to propagate this issue down the chain?
So if I do it this way, does Nitro also have to do so too b/c it
depends on tmail?

  nitro-0.50.gem
  nitro_ruby-0.50.gem

I know that's not going to happen! If tmail's install blows so does
nitro's install. Really that's simply not acceptable. There needs to
be a single gem that just works --after all that was the problem with
platform gems and that's why gem now automatically selects the right
one.

T.


More information about the Rubygems-developers mailing list