Tom Copeland [mailto:tom@infoether.com]
> > 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
On Thu, 2005-03-03 at 17:30 -0600, Curt Hibbs wrote:
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
On Mar 3, 2005, at 6:45 PM, Yukihiro Matsumoto wrote:
* dead link check
I guess what I'm saying is that when you're getting somebody to do
research on a library for the sake of a project like RPA, they have to
be extremely motivated to be able to use it long enough to have a solid
opinion on it. Whereas if you can find somebody who is actually _using_
that library to make their job easier, to work a little easier to put
food on the table, their opinions will be richer and researched with
more depth. So maybe initial efforts to reveal what projects are high
quality could start with that information.
And that's exactly what we did.
http://rpa-base.rubyforge.org/wiki/wiki.cgi?PackageAdvisor
Of course this is work in progress, but I believe this aligns well
with the ideas you expressed.
cheers,
vruz
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
On Fri, 4 Mar 2005 09:45:16 +0900, Yukihiro Matsumoto <matz@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.
[...]
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
On Fri, 4 Mar 2005 06:19:28 +0900, Jim Weirich <jim@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.
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
Hi,
Yukihiro Matsumoto wrote:
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)
Here's a result of a dead link check I did today.
http://raa.ruby-lang.org/announce20050304.html
As a side effect of the check, here are caches of homepage/downloadable
item.
http://raa.ruby-lang.org/cache/
Regards,
// NaHi
James Britt <jamesUNDERBARb@neurogami.com> writes:
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.)
+1. A generic project pinger would be very useful to register/update
stuff at rubyforge/freshmeat etc.
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
On Fri, 4 Mar 2005 07:03:40 +0900, Ben Giddings <bg-rubytalk@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.
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.
On Fri, 2005-03-04 at 07:22 +0900, Eric Hodel wrote:
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 commitsHow 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
MyNewProject v2000.0.0
Hay, looks like you've been doing lots of work on that!
When is 2005 comming out??
Tom Copeland wrote:
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
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.
On Thursday 03 March 2005 05:03 pm, Ben Giddings wrote:
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.
--
-- 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)
Quoting jim@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.
PGP.sig (186 Bytes)
On 03 Mar 2005, at 16:48, Sam Roberts wrote:
--
Eric Hodel - drbrain@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
* Sam Roberts <sroberts@uniserve.com> [2005-03-04 09:48:04 +0900]:
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 }
--
Jim Freeze
Code Red. Code Ruby
* Austin Ziegler <halostatue@gmail.com> [2005-03-04 15:06:50 +0900]:
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. 
--
Jim Freeze
Code Red. Code Ruby
Hi,
In message "Re: RAA Status & The Problem with Ruby" on Fri, 4 Mar 2005 14:45:08 +0900, leon breedt <bitserf@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.
As a side effect of the check, here are caches of homepage/downloadable
item.
http://raa.ruby-lang.org/cache/
Regards,
// NaHi
that's great, what's the current policy ?
for how long do things remain in the cache ?
are there any other 'undocumented' RAA features available ?
cheers,
vruz
Nice ideas. One note below...
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.
If you go back and look at Jamis's post, you'll see that he was
running an older version of RubyGems at the time and the performance
issues had already been fixed.
On Fri, 4 Mar 2005 15:06:50 +0900, Austin Ziegler <halostatue@gmail.com> wrote:
--
Chad Fowler
http://chadfowler.com
http://rubygems.rubyforge.org (over 100,000 gems served!)
NAKAMURA, Hiroshi wrote:
Here's a result of a dead link check I did today.
http://raa.ruby-lang.org/announce20050304.htmlAs a side effect of the check, here are caches of homepage/downloadable
item.
http://raa.ruby-lang.org/cache/
WooHoo! I a not on the list of shame, on the other hand:
NG
These 506 projects have a link to unaccessible resource via open-uri.
absolut2relativ
execution expired (Blog - Mikula Beutl - SEO Consulting)
...
ruby
550 /pub/ruby/ruby-1.8.1.tar.gz: No such file or directory (ftp://ftp.ruby-lang.org/pub/ruby/ruby-1.8.1.tar.gz)
Ruby is on the list of shame!!!
Ben
I recognize the intent of a page like this, but I don't know if it does the trick. I don't think I was use this page to help me choose a library.
Take the "ORM Packages" section ... mostly what's listed here is the libs themselves, and then a very short little brief about their compatibilities. But for me to evaluate what to use, I'd want more. How does libraries support, say, transactions? How nice is the API in general? Is configuration easy or excessively verbose? Does it make testing easy? These are the sorts of questions you can only answer sensibly if you've made a real try to use the code for something real, as opposed to just getting the install to work as an RPA volunteer. And I think they need to be _opinions_, not a consensus as suggested by a wiki page.
Particularly, what I'm looking for is information like "X programmer, whom I respect, uses Y library for Z reasons. So I will try it too." The page you sent does not currently do that.
Francis Hwang
On Mar 3, 2005, at 9:49 PM, vruz wrote:
I guess what I'm saying is that when you're getting somebody to do
research on a library for the sake of a project like RPA, they have to
be extremely motivated to be able to use it long enough to have a solid
opinion on it. Whereas if you can find somebody who is actually _using_
that library to make their job easier, to work a little easier to put
food on the table, their opinions will be richer and researched with
more depth. So maybe initial efforts to reveal what projects are high
quality could start with that information.And that's exactly what we did.
http://rpa-base.rubyforge.org/wiki/wiki.cgi?PackageAdvisor
Of course this is work in progress, but I believe this aligns well
with the ideas you expressed.