> ERROR: Error installing merb:
> ERROR: Failed to build gem native extension.
>
> /usr/bin/ruby1.8 extconf.rb install merb
> checking for sqlite3.h... no
> *** extconf.rb failed ***
> Could not create Makefile due to some reason, probably lack of
> necessary libraries and/or headers. Check the mkmf.log file for more
> details. You may need configuration options.
sudo apt-get install libsqlite3-dev
--
MK
You need to compile ruby with openssl enabled. I do not know what is
the simplest way to do it with Debian packages
since I always compile Ruby from source with a fairly simple script.
Check it out if you want:
http://gist.github.com/19803
For memcached gem (with C extension) you would need libmemcached or
something. For MySQL drivers for ActiveRecord it's
libmysqlclient15-dev or something.
--
MK
> gistfile1.sh: line 35: syntax error: unexpected end of file
This error is probably because I pasted that script with slight modifications
(original installs zsh, emacs and other things I use but others not
necessary do the same)
--
MK
For future reference, if you want openssl in ruby on debian, you can do
aptitude (or apt-get) install libopenssl-ruby
To get the bindings.
> >
It says it in the backtrace... "no such file to load -- mongrel"
Julian.
Julian
Since most of exception you got here are from rubygems, I think we should
catch them in dependency loading code and output something more friendly.
Every time someone has the same problem, I personally bitch at "damn
helpless software engineers of the 21 century, who call themselves
'Ruby rockstars'
but hardly can even read an exception trace and never read the source
code of essential Ruby software like RubyGems".
But I cannot be sure that you have any technical background at all so... :)
If you have any ideas on what error messages you'd like to see (say
"Hey, Merb cannot load gem so and so, do the following to install it.
For the list of common gotchas with some common gems see wiki page at
..."),
just leave a reply in this thread.
Again, I'd like to stress that Merb pushes RubyGems to it's limit even
when it comes to error messages.
But it only should help us make RubyGems better for everyone in the
future. So it's not a Dependency Hell (does it sound like a movie
title to you too?)
but a Growth Period instead.
--
MK
Two things.
1. I tend to agree with you about software engineers. They haven't cut
their teeth by trying to do things the hard way in much more difficult
languages - they don't fully appreciate the amount of time Ruby saves
you when writing software, because frameworks like Merb and Rails, and
for that matter even WebObjects and Java frameworks and others do so
much for you. They make it so much easier. There's so much you DON'T
have to think about. However, this is no excuse to be entirely
ignorant of these issues.
Frameworks exist mostly for experienced programmers, not new ones...
they exist because truly good programmers are defined by what they
DON'T write more than what they DO write. They spend less time writing
code because they re-use code that they already have. The sum of the
code for the web applications I've written act as a library of code
that I personally can draw on to build new web applications. I have
existing elegant solutions to common problems, so I re-use them.
Frameworks are a reflection of this, and therefore should be used by
programmers only when they have an awesome grasp of what the framework
does - or at least a rudimentary one!
2. Having said all that, people have to start somewhere. I've long
wondered why things can't be simultaneously easy, simple and
instructive, AND powerful, customizable and concise. There is
definitely a huge hole when it comes to the education of programmers,
and not least this is because the more experienced a programmer
becomes, the less "in touch" with the beginner's mind they are. It's
the same in any field. It takes a very very very special sort of
person to be able to simultaneously be young in the mind and draw on
one's experience to abstract understanding and apply it, with energy.
And another layer of special on top of that to be able to share the
experience and understanding with another (mostly because one must
understand oneself first).
There is a definite tendency towards knee-jerk reactions of pointing
blame. An open source framework is not a product you buy off the shelf
and then act like a user and expect customer support. Joining this
(and especially the larger Ruby) community, an attitude of gratitude
at being given help ought to be fostered. It was not always this easy,
and it was not always this powerful. We must not lose sight of
history. Using Merb, one is part of a web application history that
goes back many years, and sits on generations of technology. New
people need at least a sense of this, and older people need to be
mindful of this to bring respect into the equation.
Sometimes I am sitting, coding, and I'm entirely filled with what a
wonderful thing it is to be able to sit and type this wonderful code,
in this wonderful language, and have my meanings be expressed as they
are. Of course, usually after about 5 minutes of this, I get
distracted by the problem again, but at least these days the moments
of joy are far more frequent :-)
I do think that we've only just scratched the surface, though. This
language is wonderful, but there are far more expressive ways we could
convey our meanings for modelling our imagined logic.
Julian.
It's precisely because you're a nobody that makes you the ideal
candidate for giving advice on how to shape the framework. You're
actually a developer's best friend - whether they treat you as such or
not, because you're FRESH.
They're really good suggestions you have. I hope they're taken on
board. It'd make the framework much nicer, and actually much nicer
than Rails is at the moment, too.
I have to say that Merb *is* a framework (ie a set of code, but not a
product), and while Rails attempts to grab people who have no
experience in anything - let alone Ruby or web app development - Merb
is definitely targeted at the slightly-more-mature and a slightly-more-
discerning Ruby developer.
Thanks for not giving up hope, though :) You'll find that persistence,
and continually stripping back your assumptions are the best assets
you could ever have (for instance, you thought you had Mongrel
installed... I've spent countless hours on similar circular-tracing of
an issue before I realise that one or more of my assumptions was
fallacious: this is something that not just noobs do). These days I
know enough to fairly quickly re-check my assumptions down to the
lowest level I can.
Julian.