RAA Status & The Problem with Ruby

[Aredridel]

IMHO that's a shortcoming of Ruby's "require" statement to begin with.
It would be handy to be able to "require" a particular version of a
library, if you know that more recent ones don't work for you. Maybe in
Ruby 2.0 Matz can spruce up "require" a bit.

The problem with that is that you can't require foo 1.0 and foo 2.0
and have them not conflict unless the author has taken the care to
make them not use the same names.

That's why RPA's muliple versions will work as they will: You use a
version of the RPA distro, and within that, you only get one version
of a module, unless the author (or an RPA backporter) cleans up the
namespace.

You can have multiple versions of RPA installed, with different
versions available, but mixing and matching would be both difficult to
do without trying hard, and uncharted.

Especially with ruby's open classes, loading both versions of a
library at once could be very, very interesting (in a bad way)

Ari

 

[Guillaume Marcais]

How would you handle projects that don't use RubyForge CVS? That don't
use CVS?


MyNewProject v2000.0.0

And a cron job to download it every minute to bump your download counts.

I guess we are not looking for the perfect fool proof and 100% sure
system, but a way to extract some meaningful data. Will there be 'spam
like' problems? Maybe, but we have learned to filter those out,
automatically or manually.

Guillaume.

 

[Curt Hibbs]

On Thu, 3 Mar 2005 21:21:03 +0900, Alexander Kellett

A related problem, which I think had a lot to do with that person, was
that there was this "rivalry" of sorts set up between the RubyGems
packaging system and RPA, and although I never saw them as competing
efforts, it seemed to be the case that one of them had to "win". My
understanding of the RPA effort was that it had a lot to do with
quality control issues and was not quite so hung up on the packaging
approach (as long as the packaging approach was consistent).

There was never any rivalry between the RPA and RubyGems teams (perhaps this
person created the appearance of one). In fact the truth was quite the
opposite -- the developers on both teams cooperated and even shared code.

Curt

 

[Shad Sterling]

I like it pretty well, but it's got some bad problems and doesn't seem
to be under active development. (And it's written in Delphi.) I
started using it some time ago, and haven't switched because I haven't
found anything better - tho it's been awhile since I tried anything
else.

 

[Douglas Livingstone]

MyNewProject v2000.0.0
Hay, looks like you've been doing lots of work on that!

When is 2005 comming out??

 

[Ben Giddings]

Well, the stats are somewhat understood - they're based on totting up
all the bugs/downloads/pageviews/CVS checkins/forum posts for a project
and then munging them. But if I was pressed to explain exactly why a
project had a 0% activity percentile on a particular day, I would wander
off for a cup of coffee.

Right, but "activity percentile", in my experience, is not terribly
useful anyhow, and possibly even deceptive. If people really are
interested in foo-lib and keep going there, but no foo-lib development
activity is going on, wouldn't that bump up the "activity percentile"
without necessarily indicating that the software is useful, or getting
better?

*shrug*

It just seems like it would be really useful to be able to tell at a
glance whether or not a library was probably going to be good.
Something that worked something like: "If the version is greater than
1.0, many other people use it, and it has no unresolved bugs it is
probably pretty stable" => STABLE, "if the version number is less than
1.0, many other people use it, and there are daily checkins then it may
be unstable, but someone will probably listen if I report a bug" =>
UNSTABLE BUT ACTIVE. "If the version number is less than 0.4, the last
checkin was 12 months ago, and there are reported, but unfixed bugs, it
is probably not very useful" => UNSTABLE AND ABANDONED.

Hard to try to create a program to do this kind of heuristic tho.

Ben

 

[Curt Hibbs]

Simon Strandgaard suggested something like this a while back:

http://tinyurl.com/6s8ds

It could be cool...

How about if someone wrote a Rails app to do this? Would you be willing to
run it on the RubyForge server and modify your copy of GForge to link to it?

This would be way easier than trying to modify GForge (a PHP app) to do it
directly. I could envision a new project tab that when clicked would link to
the corresponding project review page for the same RubyForge project.

I know there are Rails developers who could create a working review and
ranking web app in less than a day. And I'm sure that we could easily find a
volunteer to do so if they knew it would be deployed and used by everyone
(everyone *does* use RubyForge, don't they?

Curt

 

[Douglas Livingstone]

"If the version number is less than 0.4, the last

checkin was 12 months ago, and there are reported, but unfixed bugs, it
is probably not very useful" => UNSTABLE AND ABANDONED.

Could a check for something being abandoned be based on x percentage
of bugs which have been reported in x timeframe which have not been
confirmed/assigned by the developer/s? Actual fixing of bugs is also
important, but an unactive project will show up faster if bugs are
only reported and nothing further happens. Perhaps. It assumes that a
single bug tracking system is used though.

Douglas

 

[Ben Giddings]

Could a check for something being abandoned be based on x percentage
of bugs which have been reported in x timeframe which have not been
confirmed/assigned by the developer/s? Actual fixing of bugs is also
important, but an unactive project will show up faster if bugs are
only reported and nothing further happens. Perhaps. It assumes that a
single bug tracking system is used though.

Good suggestion. There are some drawbacks, but I think it's better than
a bare "activity percentile". Maybe it's something that people
registering on rubyforge could opt into. If they use RubyForge CVS,
RubyForge bug tracking, etc. then it would be useful to them. If they
simply use RubyForge as a place to dump their binaries (or if the stats
don't make sense for the project, say the VIT project), they could
opt-out of that feature.

It's really up to Tom though. If he thinks it would make RubyForge more
useful to people, and can figure out some way to get it there it will
probably happen.

Ben

 

[Curt Hibbs]

Right, but "activity percentile", in my experience, is not terribly
useful anyhow, and possibly even deceptive. If people really are
interested in foo-lib and keep going there, but no foo-lib development
activity is going on, wouldn't that bump up the "activity percentile"
without necessarily indicating that the software is useful, or getting
better?

*shrug*

It just seems like it would be really useful to be able to tell at a
glance whether or not a library was probably going to be good.
Something that worked something like: "If the version is greater than
1.0, many other people use it, and it has no unresolved bugs it is
probably pretty stable" => STABLE, "if the version number is less than
1.0, many other people use it, and there are daily checkins then it may
be unstable, but someone will probably listen if I report a bug" =>
UNSTABLE BUT ACTIVE. "If the version number is less than 0.4, the last
checkin was 12 months ago, and there are reported, but unfixed bugs, it
is probably not very useful" => UNSTABLE AND ABANDONED.

Hard to try to create a program to do this kind of heuristic tho.

Yes it is, especially if you want to make it truly useful.

That's why I think that a very simple system of ranking (one to five stars)
and commmenting by real users of the library (just like Amazon does for
books) would be very effective and take very little effort to implement.

Curt

 

[Tom Copeland]

Right, but "activity percentile", in my experience, is not terribly
useful anyhow, and possibly even deceptive.

I concur wholeheartedly.

If people really are
interested in foo-lib and keep going there, but no foo-lib development
activity is going on, wouldn't that bump up the "activity percentile"
without necessarily indicating that the software is useful, or getting
better?

Exactly right.

*shrug*

It just seems like it would be really useful to be able to tell at a
glance whether or not a library was probably going to be good.
+1

Hard to try to create a program to do this kind of heuristic tho.

So true.

Yours,

Tom

 

[Tom Copeland]

How about if someone wrote a Rails app to do this? Would you be willing to
run it on the RubyForge server and modify your copy of GForge to link to it?

I'd give it a whirl, sure thing!

This would be way easier than trying to modify GForge (a PHP app) to do it
directly. I could envision a new project tab that when clicked would link to
the corresponding project review page for the same RubyForge project.

I know there are Rails developers who could create a working review and
ranking web app in less than a day. And I'm sure that we could easily find a
volunteer to do so if they knew it would be deployed and used by everyone
(everyone *does* use RubyForge, don't they?

Sweet!

Tom

 

[Tom Copeland]

It's really up to Tom though. If he thinks it would make RubyForge more
useful to people, and can figure out some way to get it there it will
probably happen.

Sounds like Curt might be on to something nifty with that tab thingy he
suggested...

Yours,

Tom

 

[Jim Weirich]

IMHO that's a shortcoming of Ruby's "require" statement to begin with.
It would be handy to be able to "require" a particular version of a
library, if you know that more recent ones don't work for you. Maybe in
Ruby 2.0 Matz can spruce up "require" a bit.

Actually, I'm not sure a version number on the require statement is a good
idea. Require deals with stuff at a file level. Versions are applied at a
packaging level. Version requirements are something you want to specify in
one place, not in every single require statement in an application or
library.

What you really want is the ability to say "When I ask for a file from package
XYZ, please use files from version 1.2.3 of that package". Then latter
requires will "do the right thing" without having to update every single
require statement in the program.

You can then collect the package version constraints in a centralized location
for the app, kinda like a config file. Rail applications do this with the
environment files. Makes it easy to switch a Rails app from one version of
Rails to another.

 

[Yukihiro Matsumoto]

Hi,

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

|There was never any rivalry between the RPA and RubyGems teams (perhaps this
|person created the appearance of one). In fact the truth was quite the
|opposite -- the developers on both teams cooperated and even shared code.

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.

Improving RAA is another story. Maybe we should add it a few more
features, such as

* rating system
* dead link check
* accepting update information from anyone (pages will be updated
after the moderator check)

matz.

 

[Sam Roberts]

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

Brian Schröder said:


This is incorrect.

It *is* correct.

You do need to assure that the rubygems package manager is loaded in order
to take advantage of any gems on your system. There are basically three
options:

(1) Do a "require 'rubygems'" in your code.

Change your ruby code.

(2) Launch the script with an explicit -rubygems on the command line
(e.g. ruby -rubygems your_script_name.rb)

Change your shell/command line code. If its an executable ruby script,
it means changing the #! line, which is also code. If it is run by
double-clicking in windows, it won't work, AFAIC (but I don't use
Windows).

(3) Set the RUBYOPT environment variable to be "rubygems".

Environment setup is code as well, shell code, and very hard to do in
the face of multiple shells, ssh, X (where you don't generally have
control over the environment at all), etc.

Rubygems is fundamentally broken in this respect, to put my opinion very
bluntly.

If it was a way of distributing and downloading packages, I would be a
huge fan. For some reason, they added this "feature" that forces changes
in the language, a feature that python, perl, tcl all do without in
their package management, as far as I know.

I really wish the gems folks had stuck to the packaging creation,
distribution, and installation problem, and not jammed a half-baked
solution to the versioning problem in with it.

If you wish to lock down particular version of a library, then you are
free to use the require_gem command and supply an explicit version
constraint. I know that some folks using rails have done this to support
multiple versions of rails on a single server. This is handy because
different web apps were written against different versions of rails over
time.

Could you describe how this can possibly work? I must be missing
something very deep about ruby, because you can only have one version of
a class at a time!

Or are you saying they have independent top-level apps, running
different ruby interpreters, and each choses a particular version of
rails?

But, they could do that without gems!

They would install each rails version into a particular location, and
put that location in their require path...

Now you may say to me that is a pain for them to have to do... but I
would say that what's involved in them doing that is that they would
have to do something very similar to one of your 3 things above:

1 require '../some/specific/rails.rb'

2 run their script with a -r .../some/specific/path/rails

3 set a -I in RUBYOPT that points to the rails version they want to
use...

But, instead they get the fancy tool support, and I get the pain of
doing one of the three...

Does this not seem unreasonable? Gems appears to optimize for the
special/unusual case here, at the expense of the general, doesn't it?


I see versioning problems as two kinds:

- easy: rubygems is overkill, causing more problems than it solves. If
you just need to use a particular set of packages, install and use
them.

- hard: rubygems doesn't solve the problems, and many problems have no
solution.

If rdoc needs a particular version of HtmlGen, and I make an rdoc plugin
which requires a different version of HtmlGen, well, it won't work, and
no gem magic is going to help me.

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!

This is the most elementary of problems, and it is actually a problem
that HAS a solution, in that there really exists a version of A that
satisfies X and Y. Even a slightly more complex situation just results
in a set of version statements that have no solution.

Having the .gem file warn about missing dependencies, or dependency
requirements at INSTALL time is great, any good install tool should do
this, and that would be fine, but at runtime?

So, seriously, can anybody give me examples of where the versioning was
used, what problem was solved, and how it solved it? Is there any
positive experience with this?

I hate to be negative about something that people are working so hard
on, but forcing one of the 3 "solutions" above on users of my libraries
just so that they can download and install a project of mine with a
single command line is a Bad Idea. Especially when all they had to do
before is download my package, untar, and ruby install.rb. Thats not
that hard...

As a bonus, they don't get any problems they have to solve, they don't
get multiple versions of my packages they have to uninstall, and I don't
have to build a gem...

Cheers,
Sam

 

[Curt Hibbs]

Tom Copeland [mailto:[email protected]]

to link to it?

I'd give it a whirl, sure thing!

That's all I needed to hear... I'll start a push to get this done!

Curt

 

[Sam Roberts]

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?

I do think that all rubyforge projects should automatically mirror to
RAA, as has been suggested before.

I also think that RAA entries should have a comments underneath them so
that people can add a rating/comment. That would help a bunch.

Also, the standard library docs are a mess, very incomplete, and
frustratingly hard to get documentation diffs into. I now maintain a
local tree of docs, and annotate the src with my docs as I figure out
how undocumented stuff works.

Cheers,
Sam

 

[James Edward Gray II]

* dead link check

This is a silly simple idea that could do a lot. Test listings once a
day and if there are broken links in your listing it gets pulled from
public display until you fix it. I like that idea.

James Edward Gray II

 

[Eric Hodel]

--Apple-Mail-61-594641304
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

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

Change your ruby code.

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.

Environment setup is code as well, shell code, and very hard to do in
the face of multiple shells, ssh, X (where you don't generally have
control over the environment at all), etc.

The only problem I've had with this is bourne-style shells vs.
csh-style shells (BSDs typically make root's login shell a csh-style
shell to keep you from foot-shooting, so I really don't want sharing).

I have both bash and sh using the same config files for 7 different
machines in a variety of environments. In none of these cases have I
felt that I lacked any level of control over my environment, especially
when using ssh or X.

--
Eric Hodel - (e-mail address removed) - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

--Apple-Mail-61-594641304
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCJ7RoMypVHHlsnwQRAro7AJ4y/bMGt28EHp6pVLx+Dtt0AlOdOgCguz8f
JYZRmk0Q/AEjw+N0GQTJsjY=
=DxC2
-----END PGP SIGNATURE-----

--Apple-Mail-61-594641304--