RubyForge project and gem distriubtion

D

David Ross

I think you missed the point about the orimary
functionality of rpa being
orthogonal to RubyGems. Just as Rails built itself
on top of webrick, rpa
could have built itself on top of rubygems.

I have to disagree. Batsman has plans for rpa-base and
how they are packaged. RubyGems would not even follow
the way batsman is going. Also, I suppose rpa-base
could temporarily use rubygems packages, but again,
batsman has a bigger, better vision. He has studied
package managers for the past 6 months. He studied the
mistakes they make, how they could be better, and how
they work. Also to bring to attention. Batsman
generously gave RubyGems part of the package scheme
code. Wasn't that nice of him? :)
Same point as above, rpa could provide those
advantage as a layer over
rubygems without having to reinvent the distribution
layer.

The fact that batsman wants a QA like team as what
debian has cancels *any* possibility of this
happening.
I don't see how having this discussion stifles
development. On the contrary,
I think it is very healthy.

I have to agree. As I said on the first email. It is a
constructive critique. I suppose I could have stated
the first email better, "I have to comment on how gem
automation on rubyforge is a security hazard" might
have been better. It could have sounded like I might
have been "trolling." I don't know why every time I
say something wether it be IRC, email, real life.. it
always spins off to take hours to finish.


----------------------------------
-- Name: David Ross
-- Phone: 865.539.3798
-- Email: drossruby [at] yahoo.com
----------------------------------




__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
 
V

vruz

Same point as above, rpa could provide those advantage as a layer over
rubygems without having to reinvent the distribution layer.

Please count the lines of code Mauricio Fernandez has kindly
provided to the Rubygems project.
(if that's possible, not sure who applied the code on behalf of him,
or under which user account he did that)

Add other patches Mauricio Fernandez has provided to the Rubygems
team, but were (quickly) dismissed, and later reimplemented by
the Rubygems team.

Compare this number to the total lines of code in Ruybgems.

The fact that a given person opts to have a low-profile personality
and tries not to offend a team of professional programmers by
patching a great deal of the code they have wrote, is not IMHO
a valid reason why he should submit himself to the guidelines
and work processes of a given project.

To my knowledge, Rubygems is not a blessed standard as it still claims
to be, and it's a rather uncomfortable practice within an open-source
community when people try to impose something that clearly doesn't
fit their purposes, interests, likes or dislikes.

Believe me I love good engineering, and I hate effort duplication.

But I love free speech more.
 
A

Austin Ziegler

[...]
I don't understand why the rpa folks had to reinvent the packaging
wheel here: the service they offer is orthogonal to Gems, and
could have used Gems as the distribution mechanism.

I thought I read somewhere that Gems will be using something similar
to what RPA's RPS packages offer now. Beyond that, though, there are
philosophical differences between the package managers that I don't
think are simply resolvable by reusing the distribution mechanism. I
think that both philosophies are right for certain cases and neither
case is right for other cases.

RPA's concept of cleanly interworking versions as a "release" seems
completely incompatible with RubyGems total version anarchy. At the
same time, the ability to install any version at any time --
accepting the risks involved -- is an advantage of RubyGems at the
moment. I like the ability to say "use release version 5" and get
known versions of libraries that work together nicely (at least in
theory), but also want the ability to say "use release version 5,
but use version 7 of this package".

Neither RubyGems nor RPA solves the problem ideally -- both teams
know my feelings on this :)

I do like the distinction that Mauricio has made between RPA and
RubyGems. RubyGems, to be completely useful, has to be The Standard.
Ideally, it will also be incorporated into the core of Ruby --
hopefully eliminating the need for require_gem. (I still don't like
the idea of requiring the gem name, rather than the gem's nominal
require statement -- e.g., diff-lcs rather than diff/lcs.) RPA, on
the other hand, since it works on entire "libraries", doesn't need
to be the standard. Both approaches have merit, and while I hope
that something can be done to integrate both approaches as I don't
*really* want to have to have both on my computer as a user, I don't
have an issue with doing that for the moment.

-austin
 
D

David Ross

I do like the distinction that Mauricio has made
between RPA and
RubyGems. RubyGems, to be completely useful, has to
be The Standard.
Ideally, it will also be incorporated into the core
of Ruby --
hopefully eliminating the need for require_gem. (I
still don't like
the idea of requiring the gem name, rather than the
gem's nominal
require statement -- e.g., diff-lcs rather than
diff/lcs.) RPA, on
the other hand, since it works on entire
"libraries", doesn't need
to be the standard. Both approaches have merit, and
while I hope
that something can be done to integrate both
approaches as I don't
*really* want to have to have both on my computer as
a user, I don't
have an issue with doing that for the moment.

-austin

They are both too early to even be considered to be a
part of Ruby-core. They are both too young, each are
still unstable. Both are constantly making big
changes. There needs to be more time. Maybe a year or
so?

----------------------------------------------
-- Name: David Ross
-- Phone: 865.539.3798
-- Email: drossruby [at] yahoo.com
----------------------------------------------



__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
 
C

Chad Fowler

Please count the lines of code Mauricio Fernandez has kindly
provided to the Rubygems project.
(if that's possible, not sure who applied the code on behalf of him,
or under which user account he did that)

I was going to make this point. It's kind of ridiculous to go
counting lines, but Mauricio provided a (not-yet-released) patch to
change the gem format to be tar/gz. That was indeed very helpful and
significant in size.

Add other patches Mauricio Fernandez has provided to the Rubygems
team, but were (quickly) dismissed, and later reimplemented by
the Rubygems team.

I think you're exaggerating here. I know of one patch that was the
subject of literally weeks of debate. What got implemented was based
on Mauricio's proposal but the functionality didn't match what we were
after exactly, so it was implemented from scratch.
Compare this number to the total lines of code in Ruybgems.

We welcome more. As I said, the code we've gotten from rpa-base is
great. We've also had a ton of contributions from many other members
of the community that have vastly improved the RubyGems code and
functionality.
The fact that a given person opts to have a low-profile personality
and tries not to offend a team of professional programmers by
patching a great deal of the code they have wrote, is not IMHO
a valid reason why he should submit himself to the guidelines
and work processes of a given project.

None of us would be offended by patches. A lot of the code in
RubyGems now has been completely refactored/replaced by "new" people
since it was originally created at RubyConf. This is the way open
source works. It's good.

This is not to say that we're always going to agree with every patch
that anyone sends in. It's fairly democratic. If you have an opinion
about something that should change in RubyGems, join the list and
bring it up. We're closing in on feature completion for 1.0, so it's
probably a good time.
To my knowledge, Rubygems is not a blessed standard as it still claims
to be, and it's a rather uncomfortable practice within an open-source
community when people try to impose something that clearly doesn't
fit their purposes, interests, likes or dislikes.

RubyGems was created to fill a huge hole in the community: a
"standard" way to package, publish, discover, install, uninstall, and
manage Ruby libraries. The lack thereof has been a common complaint
since I started using Ruby years ago (and probably before then). A
group of us at last year's RubyConf decided enough was enough and we
were going to do something about it.

As for the use of the word "standard", this is the project's goal.
Whether it be defacto or blessed, the Ruby community (particularly new
users) needs a "standard" way to find and install libraries. That
doesn't mean there can't be other ways. It also doesn't mean the
standard can't change. Redhat users can use rpm/yum, which comes on
with their OS, or they can switch to apt-get/dpkg. If *one* of these
packaging systems doesn't become at least a defacto standard, it
wasn't worth our effort.

Believe me I love good engineering, and I hate effort duplication.

But I love free speech more.

Me too. I don't think anyone's trying to suppress it here.

It would be interesting for Mauricio to chime in here. Whenever I
speak to him about RPA, he affirms that RPA and RubyGems are not meant
to compete. Most of the posts in this thread are about competition.
I feel like there is room for both. RubyGems is meant to be an
augmentation of RAA, with a great deal of freedom. RPA is a
replacement for RAA, with a stringent QA and release process. Not
only is there room for both, but I think they can feed each other
nicely (in code sharing, process improvement, and overall quality
improvement).

Chad
 
R

Richard Kilmer

RPA's concept of cleanly interworking versions as a "release" seems
completely incompatible with RubyGems total version anarchy. At the
same time, the ability to install any version at any time --
accepting the risks involved -- is an advantage of RubyGems at the
moment. I like the ability to say "use release version 5" and get
known versions of libraries that work together nicely (at least in
theory), but also want the ability to say "use release version 5,
but use version 7 of this package".


So, with gems you can have multiple versions of a single library installed
at the same time...cool, but maybe not commonly used (on the surface). If
you think in terms of "sets" of versioned gems however, you arrive at the
same 'library' idea, but the 'library' can co-exist with another 'library'.
In other words, if you said I want to use library 'stable' and it mods the
load path with all of the listed gems of a specified version you then
'require' just like to did before, and you get a set of gems that have been
QA'd to work together...there ya go. Oh, and with the same 'set' you could
install it (all) or nothing...so you are guaranteed a base to work from (as
far as use goes).

Simple exammple:

Set 1:
jabber4r-0-7-0
ikko-0-1-0

Set 2:
jabber4r-0-8-0
ikko-0-2-0

With gems you could have one script request Set 1 and another script request
Set 2 on the same machine, at the same time, without a problem. Who defines
the 'sets' is another issue. We don't do the 'set' thing right now, but
really, that is a minor addition.

We don't have version anarchy, we have library author autonomy.

-rich
 
C

Curt Hibbs

David said:
I have to disagree. Batsman has plans for rpa-base and
how they are packaged. RubyGems would not even follow
the way batsman is going. Also, I suppose rpa-base
could temporarily use rubygems packages, but again,
batsman has a bigger, better vision. He has studied
package managers for the past 6 months. He studied the
mistakes they make, how they could be better, and how
they work. Also to bring to attention. Batsman
generously gave RubyGems part of the package scheme
code. Wasn't that nice of him? :)

I stand corrected!

Curt
 
C

Curt Hibbs

vruz said:
Please count the lines of code Mauricio Fernandez has kindly
provided to the Rubygems project.
(if that's possible, not sure who applied the code on behalf of him,
or under which user account he did that)

Add other patches Mauricio Fernandez has provided to the Rubygems
team, but were (quickly) dismissed, and later reimplemented by
the Rubygems team.

Compare this number to the total lines of code in Ruybgems.

The fact that a given person opts to have a low-profile personality
and tries not to offend a team of professional programmers by
patching a great deal of the code they have wrote, is not IMHO
a valid reason why he should submit himself to the guidelines
and work processes of a given project.

No doubt, this is excellent and commendable!
To my knowledge, Rubygems is not a blessed standard as it still claims
to be, and it's a rather uncomfortable practice within an open-source
community when people try to impose something that clearly doesn't
fit their purposes, interests, likes or dislikes.

RubyGems aspires to be a standard, but has never claimed to be one.
Believe me I love good engineering, and I hate effort duplication.

But I love free speech more.

I agree, wholeheartedly.

Curt
 
C

Chad Fowler

No doubt, this is excellent and commendable!


RubyGems aspires to be a standard, but has never claimed to be one.

The project description on RubyForge could actually be taken as a
claim, though its spirit was more about stating a goal. And, at the
time it was created, there was no sign that anyone was competing for
that right. :)

Chad
 
V

vruz

The fact that a given person opts to have a low-profile personality
No doubt, this is excellent and commendable!

I was going to make this point, it's ridiculous to go counting lines in order
to realize of this.
RubyGems aspires to be a standard, but has never claimed to be one.

Quoting from:
http://rubyforge.org/projects/rubygems/

"RubyGems is the Ruby standard for publishing and managing third party
libraries."

But of course it's too late to fix that, once the impression has
gained mindshare in
the community.

Whilst I believe many are guided by their strong passion and most
honest behaviour,
this sort of statements can be regarded as undesirable, especially
when there is
also other people devoting countless hours, days and months of hard
work to the benefit
of this very community as well.
I agree, wholeheartedly.

Thank you Curt, and I hope all of us share this, Res Non Verba.

best,


vruz
 
C

Chad Fowler

Whilst I believe many are guided by their strong passion and most
honest behaviour,
this sort of statements can be regarded as undesirable, especially
when there is
also other people devoting countless hours, days and months of hard
work to the benefit
of this very community as well.

Agreed. Though it was, as I mentioned, a matter of timing. We were
the only ones doing anything like this at the time, and there was no
sign than anyone would ever step in. We'd been, after all, waiting
for several years.

Chad
 
J

James Britt

vruz said:
Quoting from:
http://rubyforge.org/projects/rubygems/

"RubyGems is the Ruby standard for publishing and managing third party
libraries."

But of course it's too late to fix that, once the impression has
gained mindshare in
the community.

Whilst I believe many are guided by their strong passion and most
honest behaviour,
this sort of statements can be regarded as undesirable, especially
when there is
also other people devoting countless hours, days and months of hard
work to the benefit
of this very community as well.

I confess to not having the time to read every message on ruby-talk, so
if I missed something it is likely my own fault. My impression is that
the discussion of RubyGems, and the goal of having it become a Ruby
standard (either de facto or de jure) was pretty clear. And discussion
of alternative projects was scant or non-existent.

It seems to me that RPA appears to have suddenly emerged after a period
of quiet development. If there were people opposed to RubyGems being
promoted as a standard, or the standard, I don't recall reading anything
about it until fairly recently.

Or, put another way, I believe that people were happy to see RubyGems as
a standard, even if there were disagreements over some of the
implementation details.

(But I've been predisposed to follow RubyGem progress, having seen
hyperactive geeks coding in a bar, late at night, in Austin.)

James
 
D

Dave Thomas

"How do you get to be a great musician? It helps to know the theory,
and to understand the mechanics of your instrument. It helps to have
talent. But ultimately, greatness comes practicing; applying the
theory over and over again, using feedback to get better every time.

How do you get to be an All-Star sports person? Obviously fitness and
talent help. But the great athletes spend hours and hours every day,
practicing. "

But musicians typically don't release their practice sessions.

Cheers

Dave
 
C

Chad Fowler

(But I've been predisposed to follow RubyGem progress, having seen
hyperactive geeks coding in a bar, late at night, in Austin.)

:) You should join us this year in Virginia! I'm sure there will be
something new going on in the hotel bar. To me, that's one of the
most enjoyable things about a conference like RubyConf. Getting
together with smart people and doing something creative.

Chad

(btw, RubyConf registration is still open:
http://rubycentral.org/conference !!!!)
 
W

Walter Szewelanczyk

David said:
And we haven't reached 50 yet, so there are still free Pickaxe2 copies
available.


David

Just out of curiosity, how many people normally attend these conferences?



--
Walter Szewelanczyk
IS Director
M.W. Sewall & CO. email : (e-mail address removed)
259 Front St. Phone : (207) 442-7994 x 128
Bath, ME 04530 Fax : (207) 443-6284
 
V

vruz

But musicians typically don't release their practice sessions.
Cheers
Dave

I'm lost, who is the apprentice musician here ?
Who should stop releasing their practice sessions ?

Sorry if my comment didn't seem right to you, Dave, I have
always had a great admiration for you and your work, but I don't
quite follow your line of thought here.

In fact, I quoted your Kata text because it seemed to me like it was
inconsistent with the idea you seem to be suggesting here,
(that the rpa guys should drop their project, or be assimilated by
rubygems)

It's only a matter of opinion on who will play the best tunes in the future.
At the moment, everyone is releasing practice sessions.

I would like to ellaborate more on this, I think my primary concern
is freedom of speech more than strictly technical.

I have some work to do now, I'll think more about this later.

I take the opportunity to thank everyone for the proactive approach
you are taking.

best,
vruz
 
D

David A. Black

Hi --


I think we've averaged about 47. So 50 is a non-conservative but also
non-unrealistic estimate :)


David
 
A

Ara.T.Howard

But musicians typically don't release their practice sessions.

i think the great ones realize there is nothing else but practice sessions.

regards.

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it.
| --Dogen
===============================================================================
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top