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.
So I +1 your props to the RPA guys. 
cheers,
vruz
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.
On Fri, 2005-03-04 at 05:18 +0900, Brian Schröder wrote:
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.
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 jim@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 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? 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
Has anyone checked RDE (Ruby Development Enviroment)? in SourceForge?
I just downloaded and I will try it.
--
Este correo esta libre de virus!
> 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
On Thu, 2005-03-03 at 17:30 -0600, Curt Hibbs wrote:
Hi,
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.
In message "Re: RAA Status & The Problem with Ruby" on Fri, 4 Mar 2005 08:01:14 +0900, "Curt Hibbs" <curt@hibbs.com> writes:
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
On Mar 3, 2005, at 12:44 PM, vruz wrote:
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.
On Fri, 4 Mar 2005 11:47:00 +0900, Francis Hwang <sera@fhwang.net> wrote:
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.
--
Bill Guindon (aka aGorilla)
Francis Hwang 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.
This is an appealing idea. The fewer places a developer needs to go to update information, the more reliable that information will be.
I would be nice to have a Rake task that pulls together various bits of information, assembles descriptor file, and pings some server to indicate New Stuff. (Though I believe that RAA has or had a SOAP interface, so something like this may be doable now.)
James
On Mar 3, 2005, at 9:10 PM, Curt Hibbs wrote:
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.
Yup, that's the rub - there's a lot of data in the 50+ table GForge DB
schema, and moving that data elsewhere would be tricky.
Apologies if my tone was a little harsh...I am a happy RubyForge
resident, just calling things as I thought I saw them.
No offense taken! It's good to discuss these things...
Yours,
Tom
On Fri, 2005-03-04 at 15:07 +0900, leon breedt wrote:
Maybe some tool should be created that can be voluntarily installed on
any computer.
This already exists, when using ruby gems. The statistics are available here:
http://gems.rubyforge.org/stats.html
But I agree, it would be nice to have more informative statistics.
martinus
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
On Mar 3, 2005, at 7:57 AM, Curt Hibbs wrote:
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. 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!?)
A wiki would not be the best choice for this. Anyway, this is what should be
built in to RAA.
Curt Hibbs wrote:
Randy Kramer 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
On Thursday 03 March 2005 08:07 am, Francis Hwang wrote:
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.
On Fri, 4 Mar 2005 02:55:11 +0900, vruz <horacio.lopez@gmail.com> wrote:
> 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.So I +1 your props to the RPA guys.
--
Bill Guindon (aka aGorilla)
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.
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
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
PGP.sig (186 Bytes)
On 03 Mar 2005, at 14:09, Ben Giddings wrote:
--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
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
On Fri, 2005-03-04 at 07:09 +0900, Ben Giddings wrote:
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?
I like it pretty well, but it's got some bad problems and doesn't seem
to be under active development. (And it's written in Delphi.) I
started using it some time ago, and haven't switched because I haven't
found anything better - tho it's been awhile since I tried anything
else.
On Fri, 4 Mar 2005 07:25:26 +0900, Marcelo Paniagua <paniagua@pcmxl.com.mx> wrote:
Has anyone checked RDE (Ruby Development Enviroment)? in SourceForge?
I just downloaded and I will try it.
RDE(Ruby Development Environment) download | SourceForge.net
--
Este correo esta libre de virus!
--
----------
Please do not send personal (non-list-related) mail to this address.
Personal mail should be sent to polyergic@sterfish.com.
Quoting jim@weirichhouse.org, on Fri, Mar 04, 2005 at 06:19:28AM +0900:
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