Just an idea that’s been bouncing around my head…
Using Ubuntu, there are some ruby libraries that you can download with
apt-get, mostly core ones that aren’t included in the ruby package
itself.
If rubyforge had a repository that could just be appended to
sources.list and would allow ruby libraries (suitably (re?)named to
avoid conflicts with other apt packages) which would allow downloading
of any libraries on the site(as well as dependencies) it would just be
kind of awesome.
It bugs me a little that I’m installing ruby packages into two different
locations using two different package managers.
John
I think RubyGems should be The repository for ruby code, in the same way
CPAN is, or PEAR is trying to be, and I agree, using two different
package
managers can get annoying.
Curious, what packages do you have to grab with apt vs gem?
Jason
John T. wrote:
…
It bugs me a little that I’m installing ruby packages into two different
locations using two different package managers.
Have you checked the list archives for past discussion on this topic?
It can get heated.
–
James B.
“Every object obscures another object.”
- Luis Bunuel
John T. wrote:
It bugs me a little that I’m installing ruby packages into two different
locations using two different package managers.
It bugs me, too, but since only debian/ubuntu/etc use apt as their main
repository, adding apt packages only helps split the field further
instead of bringing everyone to a single package manager. IE: You will
always have both gems and apt to worry about, no matter what.
I use Kubuntu, so it’s not like I’m a Debian hater or anything. And I
love the apt system. I’d just much rather use Gems for Ruby stuff and
know everyone’s on the same page.
John T. wrote:
It bugs me a little that I’m installing ruby packages into two different
locations using two different package managers.
I can agree with that. As I’ve said before, one only has to extend this
to other languages to realize that if this were the status quo we’d
have to deal with dozens of different package mangers. No one really
wants to do that. Which is way an offical package manager is a key
component of any operating systems.
Don’t get me wrong. I like Gems! It’s a very nice manager (for Ruby
libs). But that doesn’t address the issue. Packaging is already
fragmented enough across the variety of operating systems. It’s ironic
that in addressing that issue for Ruby the field gets fragmented more.
I’ve been working on a solution. Something I had called Sow
(http://sow.rubyforge.org) BUT PLEASE NOTE this code is undergoing some
major revision and will likely get a new name. (Release time table is
about a month). So take what’s there as merely expiremental at this
point. In anycase, the upshot is this tool transforms packages from one
format to another on the fly and installs them using your native
format. So for instance any .gem can automatically become a .deb.
That’s great in itself, but what’s really interesting is the side
effect this has. With such a tool in hand it becomes clear that you no
longer even need to package up your source code. Just distribute the
source tar/zip and this tool will make whatever package type you want
out of it transparently upon installation.
While were on the topic of RubyGems, I’ve actually been considering the
totalliy opposite direction too. Like I said, I really do like Gems. So
I’ve been wondering, what would it take to make Gems a general purpose
package manager and not just Ruby oriented? Some interesing work has
recently appeared to this end by Matthieu R. called Raven[1].
Apperaently he’s manager to pack Java .jar files into gems. It would be
interesting to see just how generalized RubyGems can become. Could it
ever become the standard package manager of a Linux distribution?
T.
[1] http://raven.rubyforge.org/
John T. said something:
It bugs me a little that I’m installing ruby packages into two different
locations using two different package managers.
One solution would be to use alien:
http://kitenet.net/~joey/code/alien.html
As far as I can tell, all that would be required is for someone to write
an Alien:
:Gem perl file.
iain
Iain D Broadfoot wrote:
People who run Debian or derivatives of Debian might. I guess us
Gentooists would prefer a utility to automate production of ebuilds from
gems, since quite a few gems are already in Portage.
quoth the M. Edward (Ed) Borasky:
People who run Debian or derivatives of Debian might. I guess us
Gentooists would prefer a utility to automate production of ebuilds from
gems, since quite a few gems are already in Portage.
It would be trivial to do so. Someone took the time to write a gems
eclass so
a valid ebuild for a package available via remote gems (using my own as
example) is:
inherit ruby gems
DESCRIPTION=“A pure Ruby library for reading metadata from Flac files”
HOMEPAGE=“badcomputer.org: flacinfoアーカイブ”
SRC_URI=“RubyGems.org | your community gem host”
LICENSE=“Ruby”
SLOT=“0”
KEYWORDS=“~x86”
IUSE=“”
USE_RUBY=“ruby18”
DEPEND=“virtual/ruby”
You could grab the needed info from the gemspec, and you don’t need the
USE_RUBY if you are sure the package will run on Ruby 1.6, 1.8 and 1.9.
-d
quoth the M. Edward (Ed) Borasky:
Yeah … too bad Portage is written in Python, isn’t it?
Ahhh, I guess you are talking about something more integrated with
portage. I
thought you were talking about a quick script that will write an ebuild
from
a gem.
I’m getting curious though and think I may look into this deeper. Looks
like
you would have to scan the metadata.gz if you dont have a gemspec.
There is some talk from some of the devs about purging gems from portage
and
having a separate utility for installing them like g-cpan for all the
Perl
cpan modules…
-d
M. Edward (Ed) Borasky said something:
Iain D Broadfoot wrote:
One solution would be to use alien:
alien
As far as I can tell, all that would be required is for someone to write
an Alien::Gem perl file.
People who run Debian or derivatives of Debian might. I guess us
Gentooists would prefer a utility to automate production of ebuilds from
gems, since quite a few gems are already in Portage.
Quoting from the page:
“Alien is a program that converts between the rpm, dpkg, stampede slp,
and slackware tgz file formats.”
So adding gem support to alien would allow gems to be installed on
debianish, redhattish and slackwarish systems which sounds like quite a
hefty chunk of linux boxes (I’d never heard of stampede before checking
up on alien).
iain