Hi Adam,
> Yes. I will release something soon. (After I finish another software
> project I'm working on). We are talking day or two :)
Ah, that's good news.
> >On the mailing list I saw two or three people working on rubygems
> >packages, but from what I saw there isn't even a concensus on what
> >the package should be called, even less about what it should do.
> >
> >Care to shed some light on this?
> Rails will not use ruby gems - it will be a native Debian package :).
Uhm... I can understand the intention, but what gives me the creeps is
not being upstream compatible. What I mean is that according to
rubygems documentation, you write this:
require 'rubygems'
require_gem 'foo'
Even worse: gems require gems.
IOW, this part of the FAQ:
Q. It'd be nice to package code as a Gem, and then have it easily
portable to many packaging systems (e.g. manual, RubyGems,
dpkg/apt-get and other distro specific packaging). A quick glance at
RubyGems suggests that installation of a package as a Gem requires
all of its dependencies to be gems also (due to require_gem).
Thoughts on this?
A. It would not be too difficult to create a convertor to
auto-generate dpkg or rpm files out of gems. It has been on the TODO
list since day 1, but it hasn't yet made it to the top of anyone's
priority list. Anyone who would like to do this for one or more
packaging systems is more than welcome!
My problem is that by packaging a gem as a regular package, you become
incompatible with upstream at the source level. Am I missing
something? Perhaps I don't understand what you mean by "native Debian
package".
> Maybe I'm not familiar with the way Perl works, but rails is a
> complete framework. It is not a bunch of libraries that can be used
> to do whatever. It is a highly integrated framework that becomes part
> of each web application. If you are looking just for a bunch of loose
> libraries, then PHP is a great tool.
First of all, I don't care about the POS that's PHP. I could write my
own security holes if I wanted to, thankyouverymuch.
Second, we are among developers, you can drop the marketing speak.
That said, my mention of Perl was only because of policy. I was really
baffled when I read ruby-policy and I didn't really know what to do
with a gem in that context.
Marcelo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
