RAA Status & The Problem with Ruby
Curt Hibbs
http://sean.typepad.com/ditto/2005/03/the_problem_wit.html
I think that this guy has really called it right. There have been a few
postings about a reworking of RAA... does anyone know the current status of
this effort?
Curt
==========================
http://sean.typepad.com/ditto/2005/03/the_problem_wit.html
The Problem with Ruby
I've been singing the praises of Ruby lately but I gotta come clean. There
are some real problems as well.
First, let me summarize my favorite points of Ruby:
1. Intuitive syntax for any OO programmer.
2. Rails is simply stated the perfect balance between a highly productive
and an easily manageable web application development environment.
3. The entire Ruby community is amazingly friendly and helpful.
Now for the bad:
1. Libraries are in an awful state. It appears nearly half of them are
abandoned. There's no consistency in reporting dependencies or interoperable
versions - and many don't bother at all.
2. Documentation is similarly weak. There doesn't seem to be any
conventions at all.
It may seem that these two points are minor, but I assure the Ruby community
that these two points are more than enough to frustrate 90% of the
programmers who are otherwise attracted to Ruby's syntax and Rails.
Especially when you consider Perl's massive library - I still find myself
using Perl when I'd like to use Ruby simply because I can easily find a Perl
module.
These two problems are serious enough that I'd suggest that Matz and
community establish specific standards for denoting how libraries are
packaged, documented, and version dependencies (with third party product, C
libraries, other Ruby libraries, etc.) are designated. I'd also suggest that
RAA come up with a mechanism for denoting abandoned libraries vs. ones that
simply don't need to be ugpraded. Maybe an auto-email once a quarter to the
developer?
Core libraries need to be merged, maintained, and updated regularly. It
seems that many Ruby users are on Mac OS X, yet rubycocoa is compiled for
1.6.1 of Ruby and OS X 10.2? The mysql libraries, last I checked, were also
a convoluted mess of different libraries. Let's just pick one and keep it up
to date.
Anyway, enough said. I think I've made my point. Great language, great web
framework (Python still doesn't have anything comparable), but horrendous
libraries.
Curt Hibbs
>
[snip]
> 1. Libraries are in an awful state. It appears nearly half of them are
> abandoned. There's no consistency in reporting dependencies or
> interoperable
> versions - and many don't bother at all.
What is really bad about this is that many of the libs that are current are
*way* better than your average library, and a few are simply *brilliant*.
Many people (especially newcomers) don't know this because this brilliance
of drowned out in a sea of dead-ends.
Curt
Nikolai Weibull
> 1. Libraries are in an awful state. It appears nearly half of them
> are abandoned. There's no consistency in reporting dependencies or
> interoperable versions - and many don't bother at all.
> 2. Documentation is similarly weak. There doesn't seem to be any
> conventions at all.
I agree. However, there are projects that radiate excellence. Anything
written by Jamis Buck, for example,
nikolai
--
::: name: Nikolai Weibull :: aliases: pcp / lone-star / aka :::
::: born: Chicago, IL USA :: loc atm: Gothenburg, Sweden :::
::: page: www.pcppopper.org :: fun atm: gf,lps,ruby,lisp,war3 :::
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
Alexander Kellett
> What is really bad about this is that many of the libs that are
> current are
> *way* better than your average library, and a few are simply
> *brilliant*.
> Many people (especially newcomers) don't know this because this
> brilliance
> of drowned out in a sea of dead-ends.
this issue comes up every few months.
yet the last real answer (rpa) basically
disappeared into the mist because people
are far more interested in talking about
the problems than actually taking some
action. rpa provides the infrastructure
needed to prevent the above from happening
via its stated procedures with respect to
test suites and api versioning.
so the question really is, which bright
spark is going to put some actual work into
this. mauricio proved that developing the
infrastructure was a job for a single devoted
person. keeping the infrastructure going
requires people to actually take an interest
in ruby's future, and actually *do something*.
Alex
Ilmari Heikkinen
> [from the blog post]
> These two problems are serious enough that I'd suggest that Matz and
> community establish specific standards for denoting how libraries are
> packaged, documented, and version dependencies (with third party
> product, C
> libraries, other Ruby libraries, etc.) are designated. I'd also
> suggest that
> RAA come up with a mechanism for denoting abandoned libraries vs. ones
> that
> simply don't need to be ugpraded. Maybe an auto-email once a quarter
> to the
> developer?
And continued in the other email:
> What is really bad about this is that many of the libs that are
> current are
> *way* better than your average library, and a few are simply
> *brilliant*.
> Many people (especially newcomers) don't know this because this
> brilliance
> of drowned out in a sea of dead-ends.
Throwing some thoughts into air:
An archive of production-quality libraries, kept up-to-date, with the
archive tools included in the stdlib. A sort of "extended stdlib." RPA?
It has a sort of standardised good practices thing in it too (
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/118064 ).
It's a marketing problem aswell. If people don't know about it, they
won't use it.
So the solution is three-fold:
1. agree on the "extended stdlib" tools and appoint a maintainer for
them
2. advertise the tools until everyone knows about them (and uses them)
3. provide advocacy on the good libraries in the form of news hype and
tutorials.
The point is that the tool needs to be in the stdlib, its package
database needs to be maintained, and it needs positive exposure.
Ilmari
--
66. The regions beyond these places are either difficult of access
because of their excessive winters and great cold, or else cannot be
sought out because, of some divine influence of the gods.
Glenn Parker
>
> An archive of production-quality libraries, kept up-to-date, with the
> archive tools included in the stdlib. A sort of "extended stdlib." RPA?
> It has a sort of standardised good practices thing in it too (
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/118064 ).
I followed that link and got to this one:
http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto
Sadly, I found that page to be 100% wikispam. Looks like
pc125.ntcpe.edu.tw was responsible. I reverted it, but I see that there
are 6 other pages affected.
One might opine that the use of easily corrupted wiki's for publishing
documentation is another problem with Ruby.
--
Glenn Parker | glenn.parker-AT-comcast.net | <http://www.tetrafoil.com/>
Martin DeMello
Francis Hwang
On Mar 3, 2005, at 7:21 AM, Alexander Kellett wrote:
> On Mar 3, 2005, at 1:07 PM, Curt Hibbs wrote:
>> What is really bad about this is that many of the libs that are
>> current are
>> *way* better than your average library, and a few are simply
>> *brilliant*.
>> Many people (especially newcomers) don't know this because this
>> brilliance
>> of drowned out in a sea of dead-ends.
>
> this issue comes up every few months.
> yet the last real answer (rpa) basically
> disappeared into the mist because people
> are far more interested in talking about
> the problems than actually taking some
> action. rpa provides the infrastructure
> needed to prevent the above from happening
> via its stated procedures with respect to
> test suites and api versioning.
I was never quite clear on how RPA was supposed to do this. Not to
criticize the work of Mauricio and others, but it seemed to me to have
a scaling problem: If you have a few volunteers trying to evaluate
hundreds of Ruby libs, they're not going to have time to really
evaluate them.
I'd like to see some sort of a website where Rubyists can sign on and
then vouch for given libraries that they use from day to day. You'd be
able to search for libs based on who else is using them--it'd be, at
the least, a more automated way to find community opinion than emailing
ruby-talk and asking "What do people use when they're trying to use
Ruby with XYZ problem?"
Francis Hwang
http://fhwang.net/
Francis Hwang
On Mar 3, 2005, at 7:28 AM, Ilmari Heikkinen wrote:
> Throwing some thoughts into air:
>
> An archive of production-quality libraries, kept up-to-date, with the
> archive tools included in the stdlib. A sort of "extended stdlib."
> RPA? It has a sort of standardised good practices thing in it too (
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/118064 ).
>
> It's a marketing problem aswell. If people don't know about it, they
> won't use it.
>
> So the solution is three-fold:
> 1. agree on the "extended stdlib" tools and appoint a maintainer for
> them
> 2. advertise the tools until everyone knows about them (and uses them)
> 3. provide advocacy on the good libraries in the form of news hype and
> tutorials.
>
> The point is that the tool needs to be in the stdlib, its package
> database needs to be maintained, and it needs positive exposure.
I don't think it's a given that just because a certain library gets
knighted as part of an "extended stdlib" that it will automatically be
well-maintained and well-documented. In fact, there are more than a few
libs in the _actual_ stdlib that have fairly crummy documentation even
today.
Sometimes I wonder if this could be helped with a little healthy
competition. If you've got a little lib that competes with other little
libs doing the same thing, you might be more eager to write docs and
fix bugs. But if the community pre-emptively approves of code that sort
of works but isn't documented at all, you're going to have less
incentive to write docs for it.
It's sort of like running a race where everybody gets a medal; you're
not going to run as hard. Maybe that sounds like a sort of Randian
perspective on competition, but I think it's worth thinking about in
the case of Ruby--especially given the way that certain libs were,
IMNSHO, brought into the standard library too quickly.
Francis Hwang
http://fhwang.net/
Curt Hibbs
>
> On Mar 3, 2005, at 1:07 PM, Curt Hibbs wrote:
> > What is really bad about this is that many of the libs that are
> > current are
> > *way* better than your average library, and a few are simply
> > *brilliant*.
> > Many people (especially newcomers) don't know this because this
> > brilliance
> > of drowned out in a sea of dead-ends.
>
> this issue comes up every few months.
> yet the last real answer (rpa) basically
> disappeared into the mist because people
> are far more interested in talking about
> the problems than actually taking some
> action. rpa provides the infrastructure
> needed to prevent the above from happening
> via its stated procedures with respect to
> test suites and api versioning.
RPA could provide a very good answer to this problem. But no matter what
happens with RPA, RAA is still the public face of Ruby libraries. It is
current state it has some obvious deficiencies. It was my understanding that
this was being worked on by someone, but I'm not sure who or where things
are with this (or perhaps the effort has stalled or never even got
started)... I'm really not sure. But, I posted this in an effort find out by
raising (once again) the problem.
Curt
> so the question really is, which bright
> spark is going to put some actual work into
> this. mauricio proved that developing the
> infrastructure was a job for a single devoted
> person. keeping the infrastructure going
> requires people to actually take an interest
> in ruby's future, and actually *do something*.
>
> Alex
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.6.0 - Release Date: 3/2/2005
>
Randy Kramer
> I'd like to see some sort of a website where Rubyists can sign on and
> then vouch for given libraries that they use from day to day. You'd be
> able to search for libs based on who else is using them--it'd be, at
> the least, a more automated way to find community opinion than emailing
> ruby-talk and asking "What do people use when they're trying to use
> Ruby with XYZ problem?"
+1!
(Another job for a wiki!?)
Randy Kramer
Curt Hibbs
A wiki would not be the best choice for this. Anyway, this is what should be
built in to RAA.
Curt
Brian Schröder
> criticize the work of Mauricio and others, but it seemed to me to have
> a scaling problem: If you have a few volunteers trying to evaluate
> hundreds of Ruby libs, they're not going to have time to really
> evaluate them.
>
> I'd like to see some sort of a website where Rubyists can sign on and
> then vouch for given libraries that they use from day to day. You'd be
> able to search for libs based on who else is using them--it'd be, at
> the least, a more automated way to find community opinion than emailing
> ruby-talk and asking "What do people use when they're trying to use
> Ruby with XYZ problem?"
Those are just halvedone thoughts but I wanted to write it up. If you
look for something with a high snr don't read further.
I really like a package system like rpa, and its great that there are
people actually doing the work of packaging libraries. If one looks at
the debian project, it is obviously quite scalable to seperate
upstream developers from packagers.
The voting website would be a possibility, or maybe just include the
possibility to browse the rpa package tree and make comments on the
packages?
The problem with this kind of things is that they are only interesting
while they sting (until you've got your needed libraries compiled and
installed) and then they are forgotten. I haven't used rpa or gems for
quite some time, because the libs I need are now installed on my
systems.
So an applause to the people doing rubforge - raa - rpa - gems etc...
you are very important, even though its only a short contact once in a
while.
sorry for the noise,
Brian
--
Brian Schröder
http://ruby.brian-schroeder.de/
Tom Copeland
> The problem with this kind of things is that they are only interesting
> while they sting (until you've got your needed libraries compiled and
> installed) and then they are forgotten. I haven't used rpa or gems for
> quite some time, because the libs I need are now installed on my
> systems.
Very true! I remember converting my Outlook data to Evolution; there
were some bugs with the import/export routines. But once I had my data
moved over, my motivation to go back and hack on that code was nil.
So I +1 your props to the Gems guys. :-)
Yours,
Tom
James Edward Gray II
I agree that this is the right way to go. We just need a little more
metadata available in the RAA, including User Ratings and Reviews.
James Edward Gray II
Daniel Berger
<snip>
> Francis Hwang
> http://fhwang.net/
I definitely think a massive code and documentation "refactoring" is in
order for both the standard library and the core itself. Almost every
time I look at the source these days, I'm thinking "jeesh" (or worse).
But, this is where that "patch" tracker on RubyForge for the Ruby
project comes in handy. It's good for doc patches, too, folks. :)
Regards,
Dan
Daniel Berger
As Martin DeMello suggested, I definitely think a merging (of some
sort) between RubyForge and the RAA is in order.
Regards,
Dan
James Britt
> Randy Kramer wrote:
>
>>On Thursday 03 March 2005 08:07 am, Francis Hwang wrote:
>>
>>>I'd like to see some sort of a website where Rubyists can sign on and
>>>then vouch for given libraries that they use from day to day.
>>
>>(Another job for a wiki!?)
>
>
> A wiki would not be the best choice for this. Anyway, this is what should be
> built in to RAA.
Good point.
James
martinus
library also use ..." For even more ideas I think a look to
http://www.43things.com/ is a good idea. Just replace the "things" with
ruby libraries/apps, and you have a wonderful tool that helps bring
together the right people :-)
martinus
Mike Woodhouse
understanding of what's available or installed or current or deprecated
or whatever. It sounds like there's a framework for pulling this stuff
together: could that pulling be achieved by a divide-and-conquer
strategy? I.e. Individuals attack a single library at a time? I might
even feel brave enough to "do" an easy one myself...
Mark Probert
On Thursday 03 March 2005 05:14, Francis Hwang wrote:
>
> I don't think it's a given that just because a certain library gets
> knighted as part of an "extended stdlib" that it will automatically be
> well-maintained and well-documented. In fact, there are more than a few
> libs in the _actual_ stdlib that have fairly crummy documentation even
> today.
>
The "usual" way around this are standards and review. If a library fails to
meets its obligations, poor documentation or whatever, then perhaps it
shouldn't make it into the general release. I am not sure how this would
work for Ruby though. Certainly, the place to start is the current library.
The second part about the libraries is one of use. There are certain
libraries that I use all the time and couldn't live without. There are
others that are essential to me every now and then (including my own ones).
And there are others that are just cool to look at and get ideas from.
It is the now-and-then libraries that would seem to be the biggest issue. For
example, if I need an database wrapper class, what am I going to use? How do
I find out which one suits my needs? Documentation is a big part, the honest
comments from users to whom these libraries are essential is another.
So, perhaps the best initial first step is to provide a user-feedback option
to RAA and rate the programs a la Tucows or similar.
Sorry for the ramble ..
--
-mark. (probertm at acm dot org)
Author of a few unused, badly documented libraries
vruz
> criticize the work of Mauricio and others, but it seemed to me to have
> a scaling problem: If you have a few volunteers trying to evaluate
> hundreds of Ruby libs, they're not going to have time to really
> evaluate them.
First of all, RPA was never intended to replace RAA.
RAA has been used as an important source of original, pristine
packages provided by developers.
As RPA encourages a number of 'Good Practices' , it is the aim that
developers have these general guidelines into account to make their
works more easily packageable for production use.
Ultimately, if every developer out there loosely followed these
recommendations, (which we believe are a good balance between
simplicity, portability and scalability ie: 'packageability') in the
future, RPA would be becoming more like RAA, and RAA more like RPA.
(but that doesn't mean RAA will cease to co-exist and evolve, RPA is
not trying to be THE standard)
What RPA is supposed to do can be read here:
http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto
The recommended Good Practices:
http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodPractices
Good API Design:
http://rpa-base.rubyforge.org/wiki/wiki.cgi?GoodAPIDesign
Packaging Nitpick Checklist:
http://rpa-base.rubyforge.org/wiki/wiki.cgi?PackagingNitpickChecklist
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.
If the scalability problem you see is in the number of volunteers or
the culture they're trying to foster, I'm sorry but I can't answer
that.
Do you know how volunteers have been consistently and actively
discouraged from joining the project ?
How do you think that could be fixed ?
Positive input is welcome.
> I'd like to see some sort of a website where Rubyists can sign on and
> then vouch for given libraries that they use from day to day. You'd be
> able to search for libs based on who else is using them--it'd be, at
> the least, a more automated way to find community opinion than emailing
> ruby-talk and asking "What do people use when they're trying to use
> Ruby with XYZ problem?"
Finally, in your last statement, I absolutely agree with you.
I'd greatly appreciate a more automated (politically unaware,
meritocratic) way to find unbiased information to learn about real
working and useful technology.
cheers,
vruz
vruz
> people actually doing the work of packaging libraries. If one looks at
> the debian project, it is obviously quite scalable to seperate
> upstream developers from packagers.
So I +1 your props to the RPA guys. :-)
cheers,
vruz
Bill Guindon
I'll jump on that bandwagon too, and I'll add a +1 for the folks at
RubyForge. I look there first, and use RAA as a backup plan.
RubyForge seems to be much more active, and far more up to date than
RAA, but that's just my take on it.
--
Bill Guindon (aka aGorilla)
James Britt
> Below, I posting the entire text of this blog entry:
>
> http://sean.typepad.com/ditto/2005/03/the_problem_wit.html
>
> I think that this guy has really called it right. There have been a few
> postings about a reworking of RAA... does anyone know the current status of
> this effort?
>
> Curt
>
> ==========================
> http://sean.typepad.com/ditto/2005/03/the_problem_wit.html
> The Problem with Ruby
<snip/>
Some possible solutions:
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've listed things
there but have more or less forgotten about their respective pages; it
is just too much extra work to have a project, maintain the README and
home page for that project; AND have to duplicate much of that
information someplace else.
RubyForge was a godsend (thanks, InfoEtherites!) if for no other reason
that it facilitates one-stop shopping for both developer and end-user.
The RAA may be like a few other things in Rubyland: a good and
appropriate idea at the time of conception, but possibly past its prime
or superseded by more effective tools and infrastructure.
James
Curt Hibbs
I pretty much agree with your assessment, but I think one more thing is
needed. There needs to be of ranking and commenting on libraries (the way
one might do with books on amazon). This would be just as useful on
RubyForge as it would be on RAA.
Curt
Lyle Johnson
<ruby-...@lypanov.net> wrote:
> this issue comes up every few months.
> yet the last real answer (rpa) basically
> disappeared into the mist because people
> are far more interested in talking about
> the problems than actually taking some
> action.
In my opinion, the lack of support for the RPA had a lot to do with,
for lack of a better phrase, poor public relations.
A certain person attached himself to the RPA project and proceeded to
make enemies of pretty much everyone in the Ruby community. If you
were hanging out on ruby-talk and/or the #ruby-lang IRC channel during
that unfortunate period, you know who I'm talking about. He seems to
have moved on, to troll in browner pastures, and for that reason it
might be a good idea for us as a community to reconsider the merits of
RPA.
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).
Tom Copeland
> I pretty much agree with your assessment, but I think one more thing is
> needed. There needs to be of ranking and commenting on libraries (the way
> one might do with books on amazon). This would be just as useful on
> RubyForge as it would be on RAA.
Simon Strandgaard suggested something like this a while back:
It could be cool...
Yours,
Tom
Daniel Berger
<snip>
> I pretty much agree with your assessment, but I think one more thing
is
> needed. There needs to be of ranking and commenting on libraries (the
way
> one might do with books on amazon). This would be just as useful on
> RubyForge as it would be on RAA.
>
> Curt
What we need to keep from the RAA:
* The recent/new uploads page
* The ability to list dependencies
* The categorization (per package, not per project)
I still like the front end stuff (name, date released, date updated,
description, etc) that you can do per package. And, since there's a
database backend on all of this, I'm not sure how you tie it into
RubyForge.
But, if someone can merge the RAA and RubyForge into one big happy
entity, I'm all for it. :)
Regards,
Dan
Austin Ziegler
> 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).
While it is certainly true that the RPA team never saw this as a case
of "one has to win," the RubyGems team has moved on the assumption
that eventually the packaging format will be integrated with Ruby at
the core. The RPA team built its own packaging format because of
perceived or actual deficiencies in the model used by RubyGems, and in
some cases, at least, they were correct -- and RubyGems has since
improved.
I personally don't know enough about packaging formats to say for
sure. I do think that it would be beneficial if the RPA packaging team
worked with the RubyGems team to provide a *single* standard packaging
system that could be integrated into Ruby and accepted by Matz. This
would make distribution and deployment much easier in so many ways for
both developers and repackagers that it wouldn't be funny.
I don't think that the two goals are incompatible. I think that how
RubyGems does things could be integrated into how the RPA team has
said it wants to do things (e.g., the RPA team is more focussed on
stable releases of groups of packages than on multiple package
versions being available and independently selectable, but with what
seems to be only a few changes in metadata, this could be made part of
RubyGems).
-austin
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca
Ben Giddings
> I pretty much agree with your assessment, but I think one more thing is
> needed. There needs to be of ranking and commenting on libraries (the way
> one might do with books on amazon). This would be just as useful on
> RubyForge as it would be on RAA.
When I saw the description of the problem, I immediately thought of how
the same is true of Sourceforge, but how one of the first things I look
for on a new Sourceforge project page is the "activity percentile" and
the last update.
Does RubyForge have similar features? If not, how hard would it be to
add to RubyForge some automated way of deciding how reliable a library
is likely to be based on a combination of:
* when it was last updated
* when it was first created
* how many people use (download) it
IMHO, as a relatively new, English-speaking Ruby programmer, I'd say
"dump RAA, use RubyForge, dump RPA, use RubyGems". Any features that
are not in RubyGems that are in RPA could probably be put in there...
though they are different goals. I think growing the already-successful
RubyGems is the easier, and more natural solution.
As for RAA vs RubyForge, RAA may be actively used by our Japanese
friends, but unless they need it, it seems like it's really broken and
maybe shouldn't be fixed.
Ben
Brian Schröder
I'm not really good informed, but as far as I know to use ruby gems
you need to change the sourcecode of your program, while rpa is a real
package installer that installs libraries into the search path. If
this is wrong, please correct me. Because somehow this information
came into my head, I decided to use rpa over rubygems.
That gems is older than rpa is not neccisarily a good sign - maybe
experience has brought better ideas into rpa. But I'm no expert and
don't want to start another rpa vs. gems war.
best regards,
Guillaume Marcais
> I'm not really good informed, but as far as I know to use ruby gems
> you need to change the sourcecode of your program, while rpa is a real
> package installer that installs libraries into the search path. If
> this is wrong, please correct me. Because somehow this information
> came into my head, I decided to use rpa over rubygems.
You don't really need to change your code. I have RUBYOPT=-rrubygems set
in my environment and I can use gem libraries completely seamlessly.
Guillaume.
Jim Weirich
Brian Schröder said:
> I'm not really good informed, but as far as I know to use ruby gems
> you need to change the sourcecode of your program, while rpa is a real
> package installer that installs libraries into the search path. If
> this is wrong, please correct me.
This is incorrect.
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.
(2) Launch the script with an explicit -rubygems on the command line
(e.g. ruby -rubygems your_script_name.rb)
(3) Set the RUBYOPT environment variable to be "rubygems".
(2) and (3) require no changes to a code base in order to work with gem
libraries. I tend to use (3).
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.
But if you don't need the explicit versioning, just a regular require
works just fine.
--
-- Jim Weirich j...@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Tom Copeland
> When I saw the description of the problem, I immediately thought of how
> the same is true of Sourceforge, but how one of the first things I look
> for on a new Sourceforge project page is the "activity percentile" and
> the last update.
>
> Does RubyForge have similar features?
Yup, there's an activity percentile thingy:
> If not, how hard would it be to
> add to RubyForge some automated way of deciding how reliable a library
> is likely to be based on a combination of:
> * when it was last updated
> * when it was first created
> * how many people use (download) it
The above pages should do that. I don't really grok the code that
generates those percentages, though, as noted in this bug posted by Ryan
Davis:
Yours,
Tom
Ben Giddings
> 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.
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.
Anyhow, I never fully understood what RPA was all about, and how it was
suppose to interact with my system's package manager. It seems like RPA
was partially about solving the fundamental problem of scattered
libraries with differing install methods, bad docs, etc. But it was
also about trying to provide a package management/installation system.
I didn't really understand how it was supposed to work together with my
system's package manager.
RubyGems was about distributing and updating libraries and apps, but
seemed more orthogonal to the system package manager because it
installed things in a special 'gems' area. Maybe the two can be
combined, so that RubyGems adopts the quality assurance aspect of RPA
while keeping it's package management abilities. Maybe it would be
possible to sort RubyGems into 'stable' and 'unstable'. A requirement
to get to stable would not just be a lack of crashing, but to have good
docs, a stable API, and be generally well-behaved.
To be effective though, someone would have to judge what qualifies as
'stable'. There would also need to be a way to demote packages from
'stable' to 'unstable' if serious bugs come up, or the packages become
unmaintained, etc.
This sounds like it would do what the RPA project was trying to do. I
*really* appreciate the effort that went into RPA, but it really seems
like there's a needless duplication of effort going on.
I love open source software, and I love the choice it offers me. On the
other hand, sometimes it's annoying that there's BSD and Linux, Emacs
and XEmacs, KDE and Gnome, RAA and rubyforge, RubyGems and RPA. If the
RPA and RubyGems folks could get together and come up with the One True
Ruby Package Management System... that would be a momentous day. I'm
sure the streets would be filled with cheering people, the skies would
open and rainbows would fill the sky, and Ruby would be that much closer
to taking over the world (benevolently of course).
On the other hand, maybe I'm wrong and RPA and RubyGems should stay
separate projects. *shrug* (I do like rainbows though)
Ben
Ben Giddings
> The above pages should do that. I don't really grok the code that
> generates those percentages, though, as noted in this bug posted by Ryan
> Davis:
If nobody understands what the stats mean, or where they come from, are
they all that useful? Maybe we should suggest a replacement as a Quiz
topic, or something similar. Given:
* The date a project was registered
* The number of times the web page was accessed
* The number of times the binary was downloaded
* The frequency of CVS commits
* The date of the last binary release
* The version number of the project
Find a way to turn that into a human-understandable idea of how risky it
would be to use this library in a project.
Ben
Eric Hodel
> If nobody understands what the stats mean, or where they come from,
> are they all that useful? Maybe we should suggest a replacement as a
> Quiz topic, or something similar. Given:
> * The frequency of CVS commits
How would you handle projects that don't use RubyForge CVS? That don't
use CVS?
> * The version number of the project
MyNewProject v2000.0.0
--
Eric Hodel - drb...@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
Marcelo Paniagua
I just downloaded and I will try it.
http://sourceforge.net/projects/rubyde/
--
Este correo esta libre de virus!
Tom Copeland
> Tom Copeland wrote:
> > The above pages should do that. I don't really grok the code that
> > generates those percentages, though, as noted in this bug posted by Ryan
> > Davis:
>
> If nobody understands what the stats mean, or where they come from, are
> they all that useful?
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.
Yours,
Tom
Aredridel
<bg-ru...@infofiend.com> wrote:
> Jim Weirich wrote:
> > 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.
>
> 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
> On 03 Mar 2005, at 14:09, Ben Giddings wrote:
>
> > If nobody understands what the stats mean, or where they come from,
> > are they all that useful? Maybe we should suggest a replacement as a
> > Quiz topic, or something similar. Given:
> > * The frequency of CVS commits
>
> How would you handle projects that don't use RubyForge CVS? That don't
> use CVS?
>
> > * The version number of the project
>
> 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
>
> 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
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.
--
----------
Please do not send personal (non-list-related) mail to this address.
Personal mail should be sent to poly...@sterfish.com.
Douglas Livingstone
>
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
>
> On Fri, 2005-03-04 at 03:54 +0900, Curt Hibbs wrote:
> > I pretty much agree with your assessment, but I think one more thing is
> libraries (the way
> > one might do with books on Amazon). This would be just as useful on
> > RubyForge as it would be on RAA.
>
> 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
> 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
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
> > 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?
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
In message "Re: RAA Status & The Problem with Ruby"
on Fri, 4 Mar 2005 08:01:14 +0900, "Curt Hibbs" <cu...@hibbs.com> writes:
|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
>
> Brian Schröder said:
>
> > I'm not really good informed, but as far as I know to use ruby gems
> > you need to change the sourcecode of your program, while rpa is a real
> > package installer that installs libraries into the search path. If
> > this is wrong, please correct me.
>
> 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
>
> On Thu, 2005-03-03 at 17:30 -0600, Curt Hibbs wrote:
> > > 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?
>
> 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
"Peña, Botp"
//I don't think that the two goals are incompatible. I think
//that how RubyGems does things could be integrated into how
//the RPA team has said it wants to do things (e.g., the RPA
//team is more focussed on stable releases of groups of
//packages than on multiple package versions being available
//and independently selectable, but with what seems to be only
//a few changes in metadata, this could be made part of RubyGems).
+10
to add: the rpa manifesto is great for creating _good_ standards for coding
and documentation.
it is very difficult for package maintainers to package/maintain topsy-turvy
codes w topsy-turvy docs. And i agree, a wiki is a good tool for coders who
have no time to docs..
btw, can we give rpa a new name? the name doesn't shine like gem :-)
kind regards -botp
//
//-austin
//--
//Austin Ziegler * halos...@gmail.com
// * Alternate: aus...@halostatue.ca
//
Sam Roberts
> Curt Hibbs wrote:
> >Below, I posting the entire text of this blog entry:
> >
> > http://sean.typepad.com/ditto/2005/03/the_problem_wit.html
> >
> >I think that this guy has really called it right. There have been a few
> >postings about a reworking of RAA... does anyone know the current status of
> >this effort?
> >
> >Curt
> >
> >==========================
> >http://sean.typepad.com/ditto/2005/03/the_problem_wit.html
> >The Problem with Ruby
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
> <snip/>
>
> Some possible solutions:
>
> 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've listed things
> there but have more or less forgotten about their respective pages; it
> is just too much extra work to have a project, maintain the README and
> home page for that project; AND have to duplicate much of that
> information someplace else.
>
> RubyForge was a godsend (thanks, InfoEtherites!) if for no other reason
> that it facilitates one-stop shopping for both developer and end-user.
>
> The RAA may be like a few other things in Rubyland: a good and
> appropriate idea at the time of conception, but possibly past its prime
> or superseded by more effective tools and infrastructure.
>
>
>
> James
>
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
> Quoting j...@weirichhouse.org, on Fri, Mar 04, 2005 at 06:19:28AM +0900:
>>
>> 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.
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.
>> (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.
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.
Curt Hibbs
>
> Quoting jamesUN...@neurogami.com, on Fri, Mar 04, 2005 at
> 03:37:54AM +0900:
> > Curt Hibbs wrote:
> > >Below, I posting the entire text of this blog entry:
> > >
> > > http://sean.typepad.com/ditto/2005/03/the_problem_wit.html
> > >
> > >I think that this guy has really called it right. There have been a few
> > >postings about a reworking of RAA... does anyone know the
> current status of
> > >this effort?
> > >
> > >Curt
> > >
> > >==========================
> > >http://sean.typepad.com/ditto/2005/03/the_problem_wit.html
> > >The Problem with Ruby
>
>
> 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
"Peña, Botp"
//> Brian Schröder said:
//>
//> > I'm not really good informed, but as far as I know to use
//ruby gems
//> > you need to change the sourcecode of your program, while rpa is a
//> > real package installer that installs libraries into the
//search path.
//> > If this is wrong, please correct me.
//>
//> This is incorrect.
//
//It *is* correct.
+10
[snipped a lot of good & practical justifications]
but i think what you are asking is rpa :-)
kind regards -botp
//Cheers,
//Sam
//
//
//
Francis Hwang
>> I was never quite clear on how RPA was supposed to do this. Not to
>> criticize the work of Mauricio and others, but it seemed to me to have
>> a scaling problem: If you have a few volunteers trying to evaluate
>> hundreds of Ruby libs, they're not going to have time to really
>> evaluate them.
>
< snip >
> 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
> On 03 Mar 2005, at 16:48, Sam Roberts wrote:
>
> >Quoting j...@weirichhouse.org, on Fri, Mar 04, 2005 at 06:19:28AM +0900:
> >>
> >>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.
>
> 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
On Mar 3, 2005, at 9:10 PM, Curt Hibbs wrote:
>
> 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
> 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
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.
--
Bill Guindon (aka aGorilla)
Sam Roberts
Maybe, rpa without the admin overhead, where anything on RAA can be
installed with it.
Actually, an RAA tool that listed all projects, any info in their page,
and downloaded the "download" link would be all that I personally
wanted. Isn't all the info in the gem already on RAA, or vice versa?
Cheers,
Sam
"Peña, Botp"
//> +10
//> [snipped a lot of good & practical justifications]
//>
//> but i think what you are asking is rpa :-)
//
//Maybe, rpa without the admin overhead,
if one needs quality, one needs an admin :-)
i am quality sensitive, especially since i'm introducing ruby in my company.
If you think about it, the admin is there to _ease_ your job. Quality
packaging is not easy.
// where anything on RAA
//can be installed with it.
ah, rubygems at rubyforge would do fine.
but then again, who would port all those raa pckages to rubyforge/gems? An
admin again, perhaps?
kind regards -botp
//
//Cheers,
//Sam
//
Sam Roberts
> Sam Roberts [mailto:srob...@uniserve.com] wrote:
>
> //> +10
> //> [snipped a lot of good & practical justifications]
> //>
> //> but i think what you are asking is rpa :-)
> //
> //Maybe, rpa without the admin overhead,
>
> if one needs quality, one needs an admin :-)
Sometimes you don't need quality.
Sometimes I need to be able to release my project, post to my mailing
list, and have my users run "favetool -get sam'sproject", and have it
work, now, whether an admin has had the time to look at my project, and
even if the project is alpha and sucks right now.
If after it is good the RPA folks want to bless it, thats great, then
you can use it at your company with an assurance of quality.
> // where anything on RAA
> //can be installed with it.
>
> ah, rubygems at rubyforge would do fine.
>
> but then again, who would port all those raa pckages to rubyforge/gems? An
> admin again, perhaps?
Well, isn't all the info in RAA sufficient to install a project?
If I can go to RAA with my web browser, go to a project page, hit the
download link, tar -xzf proj.tgz; cd proj; ruby setup.rb install...
.. maybe a script could do this?
The only reason a script couldn't is that the naming conventions aren't
strong enough (some folks use setup.rb, some use install.rb), etc.
The gem tool (and rpa, I assume) when it packages something up, what it
is really doing is enforcing a structure, so tools can work with it.
This is cool.
The way I see it is:
- gems is a nice packaging system, with the unacceptable overhead of
a poorly considered versioning system
- rpa is a nice packaing system, with the unacceptable overhead of
an external evaluation process
If you could post .rpa somewhere, and the admin team could bless some
subset later, at their leisure and discretion, I'd be happy.
If gems didn't require me to change my ruby code, or hack my
environment, I'd be happy.
So close to happiness....
Cheers,
Sam
Richard Kilmer
On 3/3/05 10:35 PM, "Sam Roberts" <srob...@uniserve.com> wrote:
>
> The gem tool (and rpa, I assume) when it packages something up, what it
> is really doing is enforcing a structure, so tools can work with it.
> This is cool.
>
> The way I see it is:
>
> - gems is a nice packaging system, with the unacceptable overhead of
> a poorly considered versioning system
>
> - rpa is a nice packaing system, with the unacceptable overhead of
> an external evaluation process
>
I thought for a while if we had a...
gem deploy (list of gems or --all)
..which deploys all the (ruby/native) libraries in the gems into a central
dir (like the standard /usr/local/lib/ruby/site_ruby/1.8 or something) then
you could have the normal 'require' stuff just work (removing gems from the
runtime) and making it just a deployment system. What do you think?
You could even have sets of gems based on a quality estimation (or version
compatibility) that would give you an RPA style check w/out the packaging by
a central entity.
-rich
Aredridel
> a poorly considered versioning system
>
> - rpa is a nice packaing system, with the unacceptable overhead of
> an external evaluation process
>
>
> If you could post .rpa somewhere, and the admin team could bless some
> subset later, at their leisure and discretion, I'd be happy.
You can! It's not well documented yet, but quite possible. The rpa tool
certainly can download from any arbitrary URL.
Ari
Jim Freeze
> I thought for a while if we had a...
>
> gem deploy (list of gems or --all)
>
> ...which deploys all the (ruby/native) libraries in the gems into a central
> dir (like the standard /usr/local/lib/ruby/site_ruby/1.8 or something) then
> you could have the normal 'require' stuff just work (removing gems from the
> runtime) and making it just a deployment system. What do you think?
I'll vote for that. ++1
Or, more likely
sudo gem deploy (list of gmes or --all)
This would make gems a great test bed. If you like it,
then put it into the system...
This should involve a relatively simple copy, right?
--
Jim Freeze
Code Red. Code Ruby
Sam Roberts
> On 3/3/05 10:35 PM, "Sam Roberts" <srob...@uniserve.com> wrote:
>
> >
> > The gem tool (and rpa, I assume) when it packages something up, what it
> > is really doing is enforcing a structure, so tools can work with it.
> > This is cool.
> >
> > The way I see it is:
> >
> > - gems is a nice packaging system, with the unacceptable overhead of
> > a poorly considered versioning system
> >
> > - rpa is a nice packaing system, with the unacceptable overhead of
> > an external evaluation process
> >
>
> I thought for a while if we had a...
>
> gem deploy (list of gems or --all)
>
> dir (like the standard /usr/local/lib/ruby/site_ruby/1.8 or something) then
> you could have the normal 'require' stuff just work (removing gems from the
> runtime) and making it just a deployment system. What do you think?
Would be a work-around, and I'm afraid it is oriented at the installer
of gems, so speaking as a library packager, it doesn't solve my
problems.
The command line tools I make that use my libraries, they do a
"require", only. If "deployment" doesn't occur, and its an optional
second step, the gem users who don't do the
gem deploy net-mdns
are going to be coming back to me and asking why my mdns.rb script won't
find net/mdns. IMHO, if deploy doesn't always occur, it still leaves me
with having to maintain different versions of scripts and libraries -
gem using, and non-gem using.
Why isn't the entire versioning thing optional? I know I'm not the only
person who doesn't like it.
As I understand it, the real benefit to keeping the installs out of the
main tree is that it makes it easy to uninstall, not that it allows
versioning. Uninstall is very important, but there are other ways of
dealing with that.
The versioning behaviours of gems should be optional, and your deploy
should be standard. If folks need different rails installs, and they
want to use gems in their apps then they know what they are doing, they
should do a
gem install --versioned
and make sure they do a
require 'ruby_gems'
require 'rails', 0.13
at the top of their scripts.
Likewise, people who do a gem install --versioned of my libraries
(net-mdns or vPim) will KNOW that my mdns.rb script won't work out of
the box for them, they are going to have to do something to make the
scripts use the particular version - but they deliberately installed
like this, they know what the workarounds are, and why they are doing
it.
Versioning is a special case, it should be treated as such.
> You could even have sets of gems based on a quality estimation (or version
> compatibility) that would give you an RPA style check w/out the packaging by
> a central entity.
I know the rpa and gems team are friendly, so I assume that the RPA guys
real goal is a coherent set of packages. I wonder it they might not
adopt the gem package format if there was a way for them to have a named
set of gems as a "coherent version", or whatever they are looking for?
Particularly if it didn't have the versioning/API change problem?
I have the impression the rpa tool was developed as a side effect, their
primary goal was producing a stable, tested, library distribution.
Sam
leon breedt
<jamesUN...@neurogami.com> wrote:
> 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 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
> On Fri, 4 Mar 2005 03:37:54 +0900, James Britt
> 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
Richard Kilmer
On 3/3/05 11:53 PM, "Sam Roberts" <srob...@uniserve.com> wrote:
> Would be a work-around, and I'm afraid it is oriented at the installer
> of gems, so speaking as a library packager, it doesn't solve my
> problems.
>
> The command line tools I make that use my libraries, they do a
> "require", only. If "deployment" doesn't occur, and its an optional
> second step, the gem users who don't do the
>
> gem deploy net-mdns
>
> are going to be coming back to me and asking why my mdns.rb script won't
> find net/mdns. IMHO, if deploy doesn't always occur, it still leaves me
> with having to maintain different versions of scripts and libraries -
> gem using, and non-gem using.
No...they need to get your library:
gem install net-mdns
And if they have RUBYOPT=rubygems
Their code looks like:
require 'net/mdns'
If they don't have the RUBYOPT, or don't want it, they can do:
gem deploy net-mdns
Or even more concise to download and deploy:
gem install net-mdns --deploy
With the --deploy option able to be set in the .gemrc or something.
The thing is you assume they install your net-mdns in site_ruby which may
not be what folks want. You need to have two steps...get the
library...deploy it in some directory that is in the $: path. This is the
same thing that setup.rb does (deploy into a dir...site_ruby default) Having
the RUBYOPT makes the deployment happen kinda magically at runtime as you
need it. The extra deploy step lets you do it without the magic runtime
require hack stuff. But the ability to target where to deploy (like --dir
my_test_dir) makes it rather powerful in that you can have lots of site_ruby
like dirs that hold sets of deployed gem libraries (.rb/.so) and $:.unshift
them for testing, etc.
Anyway, its a thought.
-rich
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
You can already do that. The project admin can turn off those features and
then the tabs don't appear.
Curt
Richard Kilmer
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
On 3/4/05 12:20 AM, "Hal Fulton" <hal...@hypermetrics.com> wrote:
> 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.
Sam Roberts
>
>
>
> On 3/3/05 11:53 PM, "Sam Roberts" <srob...@uniserve.com> wrote:
>
> > Would be a work-around, and I'm afraid it is oriented at the installer
> > of gems, so speaking as a library packager, it doesn't solve my
> > problems.
> >
> > The command line tools I make that use my libraries, they do a
> > "require", only. If "deployment" doesn't occur, and its an optional
> > second step, the gem users who don't do the
> >
> > gem deploy net-mdns
> >
> > are going to be coming back to me and asking why my mdns.rb script won't
> > find net/mdns. IMHO, if deploy doesn't always occur, it still leaves me
> > with having to maintain different versions of scripts and libraries -
> > gem using, and non-gem using.
>
> No...they need to get your library:
>
> gem install net-mdns
>
> And if they have RUBYOPT=rubygems
They don't, so the script won't work.
> Their code looks like:
MY CODE. IT'S MY CODE. Argh.
I wrote the script, I put it in the package, and I have to make two
versions of it, one assuming that my package was installed with ruby
gems in default mode, the other assuming ruby gems wasn't used or that
the user did "gem deploy".
gems has created two distinct dialects of ruby, one uses ruby's require,
and the other uses the gems require, of the same name. Code written in
ruby's dialect won't work with gems without hacking the code, or hacking
the environment.
Code written with the require_gems won't work for people who don't have
gems, even if they have the libraries.
Its a language split. It's a problem.
Having to set 'magic' environment variables or hack the code or command
line is a problem, not a fix.
> require 'net/mdns'
>
> If they don't have the RUBYOPT, or don't want it, they can do:
[snip] complex work arounds for a problem that should not have been
caused
> The thing is you assume they install your net-mdns in site_ruby which may
> not be what folks want. You need to have two steps...get the
NO. I don't assume they install in site_ruby, I assume they install
somewhere where ***ruby's require can find it***.
That can be anywhere, but if its not in the DEFAULT locations, then they
are doing something special, and *they* have to do something special to
compensate, like use -I or -rubygems in RUBYOPTS.
Note that that is RUBY's require, not gem's require.
People aren't using gems for the most part because they want versioning,
they are using it because they want packaging, but they are being forced
to hack their environment as if they had done a custom install into a
non-standard location, when all they wanted was a simple tool to
download and install a library.
Why?
[snip] description, yet again, of how gem's require is better than
ruby's because it implements versioning... and all you have to do is
hack your environment, change the way you call ruby scripts, or change
(just a little bit) of code in all your scripts
* Versioning must be optional.
* Installed packages must be available with RUBY's require.
* A package manager that doesn't install things by default where RUBY
can find them isn't a ruby package manager, its something else.
People who want to install packages in non-standard locations and use a
version selection system can, and if ruby gems gives a standard
framework to do that, great, but it needs to be optional.
Sam
leon breedt
<ma...@ruby-lang.org> wrote:
> 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
ES
Somewhat heated this discussion of yours.
I'm certainly in favour of the --deploy scheme; the whole changing of the
require subsystem is what's kept me off gems so far. It just conjures images
from "Invasion of the body snatchers," for some reason (the remake, if you must
know).
The rest of the gem stuff being absolutely brilliant, this has stuck out like
a mammoth in a peapod; I never understood why it wasn't the default behaviour
to just collect all the packages to some directory and then include that in
the search path.
> Sam
E
Jim Freeze
> MY CODE. IT'S MY CODE. Argh.
>
> I wrote the script, I put it in the package, and I have to make two
> versions of it, one assuming that my package was installed with ruby
> gems in default mode, the other assuming ruby gems wasn't used or that
> the user did "gem deploy".
If I understand correctly, you shouldn't have to make
to versions of a script that is in a library.
The person writing code calling your lib needs
to be careful (see below), but your library
(ie code in your package) shouldn't have to
be conscious that it is a gem or not.
> gems has created two distinct dialects of ruby, one uses ruby's require,
> and the other uses the gems require, of the same name. Code written in
> ruby's dialect won't work with gems without hacking the code, or hacking
> the environment.
>
> Code written with the require_gems won't work for people who don't have
> gems, even if they have the libraries.
Is it really that much trouble to write:
begin
require 'some-lib'
rescue LoadError
require 'rubygems'
require 'some-lib'
end
Maybe we could get this added to the std distro, assuming
the gems ships with the std distro.
Jim Freeze
> gem install net-mdns --deploy
Rich
I know this is a rather new idea, but would a deploy feature
have the option of installing with or without a version?
Seems like a nice thing, but maybe too complicated.
James Britt
> On Fri, 4 Mar 2005 03:37:54 +0900, James Britt
> <jamesUN...@neurogami.com> wrote:
>
>>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.
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
<j...@weirichhouse.org> wrote:
> Brian Schröder said:
>> I'm not really good informed, but as far as I know to use ruby
>> gems you need to change the sourcecode of your program, while rpa
>> is a real package installer that installs libraries into the
>> search path. If this is wrong, please correct me.
> 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
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca
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.
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
In message "Re: RAA Status & The Problem with Ruby"
on Fri, 4 Mar 2005 14:45:08 +0900, leon breedt <bit...@gmail.com> writes:
|* 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.
leon breedt
<jamesUN...@neurogami.com> wrote:
> Oh, good. *2* places to look for and download things. Which is the
> authorative source?
> can duplicate, I mean mirror, an existing RubyForge feature?
True Source to be as close to RAA/search.cpan.org as possible in terms
of UI.
search.cpan.org is the single biggest thing Perl has going for it.
That doesn't mean people don't use things like SourceForge. But
SourceForge isn't exactly where people go to find Perl modules, maybe
50 versions back, or browse through available modules. There's too
much ancillary information hitting you in the face at SF, when all you
want to do is find a project. I would argue a directory to be a better
starting point, with the directory pointing at more details about the
project.
> 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.
I have no idea where the best place for these mirrors would be, I
chose RAA arbitrarily. RAA could point at the RubyForge mirror
location, for all I care :)
Leon
Austin Ziegler
<srob...@uniserve.com> wrote:
> Quoting bo...@delmonte-phil.com , on Fri, Mar 04, 2005 at>>>> +10
>>>> [snipped a lot of good & practical justifications]
>> if one needs quality, one needs an admin :-)
> Sometimes you don't need quality.
>
> Sometimes I need to be able to release my project, post to my
> mailing list, and have my users run "favetool -get sam'sproject",
> and have it work, now, whether an admin has had the time to look
> at my project, and even if the project is alpha and sucks right
> now.
Right. And that will be RubyGems, plain and simple. RubyGems is
scheduled to make it into the core -- once it's of high enough
quality.
>>> where anything on RAA can be installed with it.
>> ah, rubygems at rubyforge would do fine.
>>
>> but then again, who would port all those raa pckages to
>> rubyforge/gems? An admin again, perhaps?
> Well, isn't all the info in RAA sufficient to install a project?
No.
This was tried a couple of years ago, and to put it bluntly, the
result sucked. It didn't run at all on a Win32 installation, and it
was hit-and-miss because there were no packaging standards at all.
Yes, there was setup.rb, but different people had different versions
that did different things. Worse, the RAA is actually better named
the RAI (Ruby Application Index), as it doesn't host anything. If
the webpage is down, then the package is uninstallable. Oops. This
is worst on personal homepages.
To this day, for my .tar.gz releases, I maintain my *own* install.rb
(and it's *good*, but it's only good for pure Ruby solutions); I'll
only switch to setup.rb or something like that if I ever need an
extension.
RubyGems solves most of this, and it solves it without much work by
the developer.
One of my unfinished projects is a Package Publisher tool that will
take your package directory, create a gem and a .tar.gz (using
Archive::Tar::Minitar), optionally digitally sign it, release it on
RubyForge (if appropriate) and update your package details on the RAA.
It got stuck on the uploading part, and then I had other projects to
work on by time I figured out the uploading part (actually, Patrick
May did).
Look at my post in the original thread (I think). It's closer than
you think, and Matz *has* indicated that a packaging system should
be in the core. This will probably be RubyGems as it is the furthest
along.
Austin Ziegler
<srob...@uniserve.com> wrote:
> MY CODE. IT'S MY CODE. Argh.
Sam: if it is an application script, then you have the ability to
solve it, too. Easily.
Look at bin/ruwiki_servlet in the Ruwiki package. I have a *single*
script that solves the problem of running in any of the
configurations that I have anticipated for Ruwiki.
If it's *not* an application script, then, well, they *know* it's a
gem, so they can do "require 'rubygems'" before requiring net/mdns.
Alexander Kellett
> Is it really that much trouble to write:
>
> begin
> require 'some-lib'
> rescue LoadError
> require 'rubygems'
> require 'some-lib'
> end
for some reason this aggravates the
hell out of me. yeah it is. i can
equate the above question with:
Is it really that much trouble to write:
#include <stdlib.h>
/* sorry, ruby sucks these days, so i've written this in c, hope you
don't mind */
blah blah blah blah
there's a pretty dang good reason
that i use ruby. scripts are short
and pretty. if i wanted to write gob
loads of stub code i'd use java.
this bullshit that gem's introduces
makes my scripts look like hell and
i for one refuse to add it.
</rant>
Alex
gabriele renzi
> On Mar 3, 2005, at 6:45 PM, Yukihiro Matsumoto wrote:
>
>> * 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.
>
maybe no need to check every day. A full link-check cycle every week or
two week would be good anyway, if the information "this peoject was
checked x days ago" was made available
gabriele renzi
> 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.
IIRC Tcl has something like
package require version > x.y.z
I think you have to consider that rubygems does what he do since it
means to be integrated into core ruby. Once this happens you won't need
more hacks. This does not relieve of the needs for QA, anyway.