RAA Status & The Problem with Ruby

[Curt Hibbs]

Quoting (e-mail address removed), on Fri, Mar 04, 2005 at
03:37:54AM +0900:


I don't agree at all. I go first to RAA, then google, I've never
searched rubyforge.

Why should somebody have to put their package on rubyforge if they have
a place they'd rather do their development?

There are many projects on RubyForge that do not host their project there.
Ruby on Rails is a good example. It is hosted on its own servers, tracks
bugs and issues on its own servers, but releases RubyGems to RubyForge for
easy download and install.

Curt

 

[Francis Hwang]

About the scaling problem, with respect to its developer base, it has
the potential of being as scalable as any other open source project.

If you're talking about volunteers' turnaround efficiency, I
personally remember I found an undeclared dependency in Lafcadio,
understood the problem, reported it and it was fixed in the
corresponding RPA package within 24 hs. just to give an example.
I personally tested dozens of packages in at least 3 platforms.

Yes, I remember that, and I appreciate the work. But while it's one
thing to say "this code looks documented, and it installs without
breaking apart", it's another thing to say "this code is document, and
I use it all the time, and I can tell you from experience that it's
robust, the API is stable, and the maintainer is available and
responsive to bug reports." It seems to me like it takes a tremendous
amount of time to be able to say the second thing. In fact, I'd guess
that based on the relatively small download counts Lafcadio gets, there
aren't many people who can say that about my lib. Other than me, of
course, and I'm sort of biased.

I guess what I'm saying is that when you're getting somebody to do
research on a library for the sake of a project like RPA, they have to
be extremely motivated to be able to use it long enough to have a solid
opinion on it. Whereas if you can find somebody who is actually _using_
that library to make their job easier, to work a little easier to put
food on the table, their opinions will be richer and researched with
more depth. So maybe initial efforts to reveal what projects are high
quality could start with that information.

Francis Hwang
http://fhwang.net/

 

[Sam Roberts]

Quoting (e-mail address removed), on Fri, Mar 04, 2005 at 10:06:00AM +0900:

You have to add a require line somewhere in your code to load any
library, so I don't see what the problem with this one is. Libraries
have never magically appeared for me.

Libraries have never magically *disappeared* for me because a
packaging/installation tool put them in a place the runtime doesn't
look for them. Until gems.

Did you completely miss the point of Jim's claim, that you don't have to
do anything special in your code to use a gem?

That you have an amazing personal setup allowing you to get RUBYOPT
defined everywhere is hardly the point - that you have to do the setup
after deciding to use gems (or use one of the other two solutions) is
the point.

Sam

 

[Francis Hwang]

There are many projects on RubyForge that do not host their project
there.
Ruby on Rails is a good example. It is hosted on its own servers,
tracks
bugs and issues on its own servers, but releases RubyGems to RubyForge
for
easy download and install.

Yes, but should they have to do that to be considered alongside all the
other Ruby libs? There are a number of pretty great libs that don't
release to RubyForge. Personally, I use it 'cause, well, I'm lazy. But
I don't think everybody should have to.

I think ideally, this would be handled generally using some basic sort
of publish-update mechanism. The DOAP project is well-suited for this,
and in theory could be integrated with FOAF. Then you could release
your lib wherever, and ping the right servers to go slurp your updated
DOAP file, then people would have a lot of personal choice as to where
they host their libs.

Francis Hwang
http://fhwang.net/

 

[vruz]

I guess what I'm saying is that when you're getting somebody to do

research on a library for the sake of a project like RPA, they have to
be extremely motivated to be able to use it long enough to have a solid
opinion on it. Whereas if you can find somebody who is actually _using_
that library to make their job easier, to work a little easier to put
food on the table, their opinions will be richer and researched with
more depth. So maybe initial efforts to reveal what projects are high
quality could start with that information.

And that's exactly what we did.

http://rpa-base.rubyforge.org/wiki/wiki.cgi?PackageAdvisor

Of course this is work in progress, but I believe this aligns well
with the ideas you expressed.

cheers,
vruz

 

[Bill Guindon]

Yes, but should they have to do that to be considered alongside all the
other Ruby libs? There are a number of pretty great libs that don't
release to RubyForge. Personally, I use it 'cause, well, I'm lazy. But
I don't think everybody should have to.

I think ideally, this would be handled generally using some basic sort
of publish-update mechanism. The DOAP project is well-suited for this,
and in theory could be integrated with FOAF. Then you could release
your lib wherever, and ping the right servers to go slurp your updated
DOAP file, then people would have a lot of personal choice as to where
they host their libs.

That sounds like a great answer... generic release data (dev, name,
date, desc, etc.), an open API to the data, then anybody can display
it as they see fit (RAA, RubyForge, etc.) Categorization could be a
problem tho.

 

[leon breedt]

1. Dump the RAA.
Don't bother fixing it.
Tell people to move their code to RubyForge.

2. Dump the RAA
Tell people to find a home page for their
project and include "RAA" and "Ruby" in the keyword meta tag,
and let Google do the rest.

2. Dump the RAA
Tell people to find a home page for their
project and tag it on del.icio.us with the tags 'Ruby'
and 'RAA', plus a brief description.
I get the sense that this blogger's opinion was based entirely on what
he saw at the RAA. RAA has pretty much fallen off my radar; If I'm
looking for a Ruby app or lib I turn to RubyForge or Google. The RAA
has tended to be too incomplete or out-of-date.

I disagree strongly with this "dump the RAA" verdict.

I don't understand the desire to dump something simply because it is
out of date. There is nothing wrong with its core fundamentals. Its
only problem is that it is not that up to date, but that is a solvable
problem.

If it was up to date, and had mirroring capabilities, it would serve
as an excellent directory and central download repository for
anything, including .gem/.rpa. RAA's virtue is its extreme simplicity.
In terms of browsing software, and finding something quickly, its UI
beats RubyForge hands down.

My major beef with the RubyForge/GForge/SourceForge is that for every
single project you register, the assumption is made that you want the
entire set of project lifecycle features, and clutters your project
page with every single feature of the software. To me, thats worse.

I'm not saying its not providing a valuable service. But trying to
provide everything to everyone has never seemed to work out in the
real world. What is RubyForge's core valuable feature? An SCM
repository, mailing lists, and a Wiki, and stats/news on the
registered projects, and central downloads.

So why not add mirroring capabilities to RAA and have RubyForge focus
on the things that make it useful? And have RAA be the directory, with
RubyForge having being taught to speak to RAA.

Less is more...

Leon

 

[Jim Freeze]

Or say I have:

A - v 3, 4, 5 installed
B - a script I downloaded and run
B requires X, which needs A with version >=3
-> I'll get version 5, right/
B requires Y, which needs A with version <= 4
-> It will die, right?

So, now I trouble shoot... and uninstall A version 5. How did rubygems
help me? I could have done this without ruby gems!

:>V

For singular library version requirements, gems works fine.
For multiple library version requirements, gems provides the
capability to load different versions of a library, but still
has the problem of the classes having the same names.
I think this could be solved elegantly with selector namespaces,
but they aren't here yet.

<thinking out loud>
Hmm, could a little discipline in module definition and usage help
out here?.

module V123
class Fred
end
end

module V234
class Fred
end

versions = []
versions << require('fred', '123') # returns ref to module V123
versions << require('fred', '234') # returns ref to module V234

versions.each { |v| v::Fred.new }

 

[Sam Roberts]

Quoting (e-mail address removed), on Fri, Mar 04, 2005 at 02:04:51PM +0900:

On Fri, 4 Mar 2005 03:37:54 +0900, James Britt
I disagree strongly with this "dump the RAA" verdict.

If it was up to date, and had mirroring capabilities, it would serve
as an excellent directory and central download repository for
anything, including .gem/.rpa. RAA's virtue is its extreme simplicity.
In terms of browsing software, and finding something quickly, its UI
beats RubyForge hands down.
++100

My major beef with the RubyForge/GForge/SourceForge is that for every
single project you register, the assumption is made that you want the
entire set of project lifecycle features, and clutters your project
page with every single feature of the software. To me, thats worse.

I agree. In fairness, a lot of the features can be turned off by the
project admins, but most don't, and its still noisy.

I'm not saying its not providing a valuable service. But trying to
provide everything to everyone has never seemed to work out in the
real world. What is RubyForge's core valuable feature? An SCM
repository, mailing lists, and a Wiki, and stats/news on the
registered projects, and central downloads.

So why not add mirroring capabilities to RAA and have RubyForge focus
on the things that make it useful? And have RAA be the directory, with
RubyForge having being taught to speak to RAA.

Yes!

Sam

 

[Hal Fulton]

My major beef with the RubyForge/GForge/SourceForge is that for every
single project you register, the assumption is made that you want the
entire set of project lifecycle features, and clutters your project
page with every single feature of the software. To me, thats worse.

I'm not saying its not providing a valuable service. But trying to
provide everything to everyone has never seemed to work out in the
real world. What is RubyForge's core valuable feature? An SCM
repository, mailing lists, and a Wiki, and stats/news on the
registered projects, and central downloads.

That gives me an interesting idea. What if the unused features
for a project weren't visible?

Would that be hard to hack up? Tom C, are you reading?

I know that I for one *frequently* visit the tabs for a project
and find there is nothing there (especially the Docs).

I'd like it if the links that led to dead ends could be somehow
grayed-out or made unclickable.


Hal

 

[Martin DeMello]

That sounds like a great answer... generic release data (dev, name,
date, desc, etc.), an open API to the data, then anybody can display
it as they see fit (RAA, RubyForge, etc.) Categorization could be a
problem tho.

If you meain hierarchical categorisation, I think tagging would be more
useful anyway.

martin

 

[Curt Hibbs]

That gives me an interesting idea. What if the unused features
for a project weren't visible?

Would that be hard to hack up? Tom C, are you reading?

I know that I for one *frequently* visit the tabs for a project
and find there is nothing there (especially the Docs).

I'd like it if the links that led to dead ends could be somehow
grayed-out or made unclickable.

You can already do that. The project admin can turn off those features and
then the tabs don't appear.

Curt

 

[Richard Kilmer]

I disagree strongly with this "dump the RAA" verdict.

I don't understand the desire to dump something simply because it is
out of date. There is nothing wrong with its core fundamentals. Its
only problem is that it is not that up to date, but that is a solvable
problem.

If it was up to date, and had mirroring capabilities, it would serve
as an excellent directory and central download repository for
anything, including .gem/.rpa. RAA's virtue is its extreme simplicity.
In terms of browsing software, and finding something quickly, its UI
beats RubyForge hands down.

The RubyForge team has always viewed RAA as THE project metadata repository
for the Ruby community. There are lots of folks (1,700+) who house over 500
ruby projects on RubyForge right now. Many don't use all the features, that
is true, but many developers don't have a place on the net to store their
code/projects...thus the reason we stood RubyForge up.

My major beef with the RubyForge/GForge/SourceForge is that for every
single project you register, the assumption is made that you want the
entire set of project lifecycle features, and clutters your project
page with every single feature of the software. To me, thats worse.

Worse than what? Its not worse if you have no other place to put stuff.
You don't need to use it...no one is forcing that...its just an available
service that we pay $$ for to provide something that we saw was missing.

I'm not saying its not providing a valuable service. But trying to
provide everything to everyone has never seemed to work out in the
real world. What is RubyForge's core valuable feature? An SCM
repository, mailing lists, and a Wiki, and stats/news on the
registered projects, and central downloads.

So why not add mirroring capabilities to RAA and have RubyForge focus
on the things that make it useful? And have RAA be the directory, with
RubyForge having being taught to speak to RAA.

It was our intent to do this, time has gotten the best of that intention,
but its 'on the list'. Our idea was to have RubyForge projects
auto-populate the RAA as those projects release files, edit their metadata,
etc. Its an integration effort that we have not had the time to do yet,
that's all. Insofar as searching for things, I agree that RAA is fast and
simple to use. It would make a nice interface plugin for RubyForge to have
the RAA search box on the main screen.

Less is more...

Leon

If less is more why use gmail ;-)

-rich

 

[Richard Kilmer]

That gives me an interesting idea. What if the unused features
for a project weren't visible?

Would that be hard to hack up? Tom C, are you reading?

I know that I for one *frequently* visit the tabs for a project
and find there is nothing there (especially the Docs).

I'd like it if the links that led to dead ends could be somehow
grayed-out or made unclickable.

Each project admin can turn off tabs, but that is up to them.

 

[leon breedt]

I think there's need for both a packaging "system" and a package
repository. I wish for a sound cooperation of the former (rubygems?)
and the latter (rpa?). I'd happy to merge the packaging system (with
which both teams can agree) in the standard Ruby.

In my mind, the problem consists of these components, each caring only
about their small area of responsibility:

* Package builder, which generates, from a "recipe": (1) an artifact
that can be installed on a host or (2) an artifact reusable by
repackagers to create a platform-specific (1) (i.e. RPM). All it does
is generate these artifacts.

* Central repository (RAA?), mirrored, containing the (1) and (2)
artifacts, and only serving downloads for the "installer" below.

* Package installer, which obtains (1) artifacts from central
repository and installs them and does only that.


This doesn't mean that people won't have both the builder and
installer available on their systems. But I do think they should be
discrete components with distinct areas of responsibility.

Leon

 

[James Britt]

I disagree strongly with this "dump the RAA" verdict.

I don't understand the desire to dump something simply because it is
out of date. There is nothing wrong with its core fundamentals. Its
only problem is that it is not that up to date, but that is a solvable
problem.

Indeed it is; the question I'm trying to provoke is, Is that the best path?

If it was up to date, and had mirroring capabilities, it would serve
as an excellent directory and central download repository for
anything, including .gem/.rpa. RAA's virtue is its extreme simplicity.
In terms of browsing software, and finding something quickly, its UI
beats RubyForge hands down.

Oh, good. *2* places to look for and download things. Which is the
authorative source?

My major beef with the RubyForge/GForge/SourceForge is that for every
single project you register, the assumption is made that you want the
entire set of project lifecycle features, and clutters your project
page with every single feature of the software. To me, thats worse.

I'm not saying its not providing a valuable service. But trying to
provide everything to everyone has never seemed to work out in the
real world. What is RubyForge's core valuable feature? An SCM
repository, mailing lists, and a Wiki, and stats/news on the
registered projects, and central downloads.

So why not add mirroring capabilities to RAA and have RubyForge focus
on the things that make it useful? And have RAA be the directory, with
RubyForge having being taught to speak to RAA.

Less is more...

Indeed.

How is this less? Adding another feature to RubyForge so that the RAA
can duplicate, I mean mirror, an existing RubyForge feature?

The idea of mirroring select aspect of RubyForge (downloads,
project/stat indices) is worth considering, but then we're no longer
talking about RAA; this a new project, and simply redefining the RAA as
a lightweight mirror of RubyForge is just sleight-of-hand.



James

 

[Austin Ziegler]

Brian Schröder said:
This is incorrect.

[...]

Only in the specifics. In the general case, though, it's correct. I
consider setting RUBYOPT a Bad Thing, and the requirement of either
specifying -rubygems or "require 'rubygems'" only marginally less
bad.

Granted, when RubyGems 1.0 hits the street, as it were, it is my
understanding that Matz wants this as part of the core, and RubyGems
has been planned from the beginning as working in the core.

IMO, the following things need to be done to make RubyGems the core
packaging format AND make it work well with the concept of RPA-
stable libraries; this is recent formulation, and I haven't
discussed it with anyone:

1. Make RubyGems transactional. This is one of the things that I
think that Mauricio got absolutely right. As it stands now, I
think that it is possible for a RubyGem install to fail in the
middle and leave me in a state where I can partially include
something.

2. Make RubyGems aware of the package files that it owns. This is
what RPA did to ensure that it could install the library into
the core library area without breaking anything else.

3. Provide patches to 1.8.x and probably 1.9 that would replace
the require functionality with the RubyGems require, but
faster. See the RubyGems/rails performance boost tip someone
(Jamis?) found some time back. That startup performance hit is
a strong negative against RubyGems. RPA didn't face this
because it *did* put the package files in the core.

4. Make it possible for a version mapping to be provided, but let
RubyGems sanity check that version mapping. What do I mean
here?

RPA.version = 2

RPA.version_mapping # =>
{ 2 => [ "rails-0.10.0", "text-format-1.0", ... ] }

The exact format I haven't figured out, but this would be a way
of providing the RPA stable versions I talked about.

There are other things, and I'm so overworked right now I don't even
have time to think (I've still got to get Text::Format 1.0,
PDF::Writer 1.0, color-management 1.0, and ruby-ttf2afm 1.0 out the
door), much less contribute more than ideas at this point.

-austin

 

[leon breedt]

Worse than what? Its not worse if you have no other place to put stuff.
You don't need to use it...no one is forcing that...its just an available
service that we pay $$ for to provide something that we saw was missing.

I wasn't clear: I'd rather see it opt-in than opt-out. Otherwise, it
looks like you're neglecting the project or not maintaining it (take
Rails for example), while it actually is quite active.

Perhaps the notion of being able to specify on the summary page the
primary places of activity for the project (such as the mailing lists,
wiki, bug tracker, SCM, etc) if they're non default, would help here.

It was our intent to do this, time has gotten the best of that intention,
but its 'on the list'. Our idea was to have RubyForge projects
auto-populate the RAA as those projects release files, edit their metadata,
etc. Its an integration effort that we have not had the time to do yet,
that's all. Insofar as searching for things, I agree that RAA is fast and
simple to use. It would make a nice interface plugin for RubyForge to have
the RAA search box on the main screen.

Are we really stuck with GForge in the long term? It would be great if
there were plans to switch to a Ruby framework, and a more Rubyist
approach was taken to the design of the site. Especially if the design
folks behind the ruby-lang.org redesign had a hand in the appearance
and UI. I understand it would be a massive migration effort though.

Apologies if my tone was a little harsh...I am a happy RubyForge
resident, just calling things as I thought I saw them.

Leon

 

[Jim Freeze]

1. Make RubyGems transactional. This is one of the things that I
++1

4. Make it possible for a version mapping to be provided, but let
RubyGems sanity check that version mapping. What do I mean
here?

RPA.version = 2
RPA.version_mapping # =>
{ 2 => [ "rails-0.10.0", "text-format-1.0", ... ] }

Hmm, good idea. I'm not sure if I would never use this or
if I would use it exclusively.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: RAA Status & The Problem with Ruby"

|* Central repository (RAA?), mirrored, containing the (1) and (2)
|artifacts, and only serving downloads for the "installer" below.

RAA would refuse to be a central repository. Despite the name, it is
(and will be) the central _index_ of the various Ruby projects. RPA
might be a candidate for the central.

matz.