Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > An alternative to Gems

Reply
Thread Tools

An alternative to Gems

 
 
Trans
Guest
Posts: n/a
 
      11-19-2005

As I've mentioned before, I am concerned about Ruby becoming tied to
RubyGems. I am concerned because I think Gems overly complicates Ruby's
require mechanism, making it less efficient than it needs to be and
sometimes causing unexpected load behaviors. Even more worrisome to me
though is that Gems ties require versioning (and some of it's other
benefits) to *package distribution*. B/c of this I fear Gems will
become the ONLY acceptable way to distribute Ruby software --indeed, it
already seems to be doing so. Maybe some people want that, but I fear
it locks Ruby in too much, and stiffles any future innovation in the
distribution area.

For these reasons I'm inquiring into the support that may exist for
doing things a little differently. I believe it would be better if
Ruby itself simply elaborated on its #require method (and #load method
of course) to handle versioned directory tiers. Then simply by adding a
version tier to a project's lib/ path versioning would be supported --
independent of any distribution mechinism. To be clear, what I mean is
instead of this:

myproject/
lib/
myproject/
myfile.rb

One would put:

myproject/
lib/
myproject/
1.0.0/
myfile.rb

So even setup.rb can be used just as it always has and versioning would
be supported.

I want to make clear that I am not wishing away Gems in this, I like
Gems and think is makes a great package manager for Ruby. I simply
think the versioning should not be dependent on Gems. And Gems could be
adapted to work with the above system too.

So I'd like to know if others would be in support of this approach as I
have already written a system to do exactly this. The system deals with
all the details that arise doding this and adds some additional
benefits, but the above is heart of the matter. The system is nearly
ready for release. I am down to completing thread safety and
solidifying the exact require interface that will support it.

So what do you think? Anything you'd like me to clarify? Is there
support out there for pursuing this approach?

Thanks,
T.

 
Reply With Quote
 
 
 
 
Kevin Brown
Guest
Posts: n/a
 
      11-19-2005
On Saturday 19 November 2005 12:57, Trans wrote:
> For these reasons I'm inquiring into the support that may exist for
> doing things a little differently.


I use rubyscript2exe to package whatever I'm dealing with, as usually it's
just very nice to have a single executable. Yes, it isn't a
library/whatever, but for apps, that's what I usually end up doing.


 
Reply With Quote
 
 
 
 
Austin Ziegler
Guest
Posts: n/a
 
      11-19-2005
On 11/19/05, Trans <(E-Mail Removed)> wrote:
> As I've mentioned before, I am concerned about Ruby becoming tied to
> RubyGems.


Yes, you have. I, however, am not. I think you're worried about nothing.

> I am concerned because I think Gems overly complicates Ruby's
> require mechanism, making it less efficient than it needs to be and
> sometimes causing unexpected load behaviors.


I think that it is less complex than the mess that you have tried to
introduce with Facets.

> Even more worrisome to me
> though is that Gems ties require versioning (and some of it's other
> benefits) to *package distribution*.


A tiny speck of thought about this would actually make it quite clear
that this is the only sane way to approach the problem (e.g., making
it so that packaging and versioning *work together*). I have yet to
see anyone else propose anything that is remotely reasonable in any
way.

> B/c of this I fear Gems will
> become the ONLY acceptable way to distribute Ruby software --indeed, it
> already seems to be doing so. Maybe some people want that, but I fear
> it locks Ruby in too much, and stiffles any future innovation in the
> distribution area.


Doubtful.

> For these reasons I'm inquiring into the support that may exist for
> doing things a little differently. I believe it would be better if
> Ruby itself simply elaborated on its #require method (and #load method
> of course) to handle versioned directory tiers. Then simply by adding a
> version tier to a project's lib/ path versioning would be supported --
> independent of any distribution mechinism. To be clear, what I mean is
> instead of this:


What you're asking for is a half-assed barely-considered approach that
doesn't even address the a single problem that people legitimately
have with RubyGems. It's nonsense.

> One would put:
>
> myproject/
> lib/
> myproject/
> 1.0.0/
> myfile.rb
>
> So even setup.rb can be used just as it always has and versioning would
> be supported.


Ah. Please, litter my system with all kinds of garbage that isn't
cleanly tied together! What you have proposed has exactly *zero*
advantage over RubyGems and probably has several disadvantages, not
least of which putting the versioning *completely* out of Ruby's
hands, which is the problem that is trying to be solved in the first
place.

> I want to make clear that I am not wishing away Gems in this, I like
> Gems and think is makes a great package manager for Ruby. I simply
> think the versioning should not be dependent on Gems. And Gems could be
> adapted to work with the above system too.


I hope not, because what you've described is nonsense.

> So I'd like to know if others would be in support of this approach as I
> have already written a system to do exactly this. The system deals with
> all the details that arise doding this and adds some additional
> benefits, but the above is heart of the matter. The system is nearly
> ready for release. I am down to completing thread safety and
> solidifying the exact require interface that will support it.
>
> So what do you think? Anything you'd like me to clarify? Is there
> support out there for pursuing this approach?


Yeah -- if you really want to propose an alternative, code it. No,
really. Sit down and code it out. Start finding out what the problems
with your approach would be. I'm *really* tired of people being lazy
backseat drivers to the problems that the RubyGems team has *solved*.
If you don't like what RubyGems does, provide something else as a
reasonable alternative.

Otherwise, STFU. Please.

-austin
--
Austin Ziegler * http://www.velocityreviews.com/forums/(E-Mail Removed)
* Alternate: (E-Mail Removed)


 
Reply With Quote
 
Austin Ziegler
Guest
Posts: n/a
 
      11-19-2005
On 11/19/05, Austin Ziegler <(E-Mail Removed)> wrote:
> On 11/19/05, Trans <(E-Mail Removed)> wrote:
> > So what do you think? Anything you'd like me to clarify? Is there
> > support out there for pursuing this approach?

>
> Yeah -- if you really want to propose an alternative, code it. No,
> really. Sit down and code it out. Start finding out what the problems
> with your approach would be. I'm *really* tired of people being lazy
> backseat drivers to the problems that the RubyGems team has *solved*.
> If you don't like what RubyGems does, provide something else as a
> reasonable alternative.
>
> Otherwise, STFU. Please.


To be perfectly and painfully clear: I'm not just talking to Trans
here. I'm talking to anyone who has kvetched about the fact that
RubyGems is going into the core at some point in the future. Put up
(code, not bullshit) or shut up. It's tiresome and discouraging to see
that some people aren't interested in actually solving problems but
rather continuing to snipe.

-austin
--
Austin Ziegler * (E-Mail Removed)
* Alternate: (E-Mail Removed)


 
Reply With Quote
 
Andreas Schwarz
Guest
Posts: n/a
 
      11-19-2005
halostatue wrote:
> On 11/19/05, Trans <(E-Mail Removed)> wrote:
>> So I'd like to know if others would be in support of this approach as I
>> have already written a system to do exactly this.


...

> Yeah -- if you really want to propose an alternative, code it. No,
> really. Sit down and code it out. Start finding out what the problems
> with your approach would be. I'm *really* tired of people being lazy
> backseat drivers to the problems that the RubyGems team has *solved*.


Sometimes it could help to actually read the post you are replying to.

> Otherwise, STFU. Please.


I think you have a problem with criticism.

--
Posted via http://www.ruby-forum.com/.


 
Reply With Quote
 
Jim Freeze
Guest
Posts: n/a
 
      11-19-2005
On 11/19/05, Austin Ziegler <(E-Mail Removed)> wrote:

> > Yeah -- if you really want to propose an alternative, code it.


I haven't been following this thread and I don't know what has
been said, nor do I really care. But, if, as suggested, there are
those complaining about rubygems, then the best case they
can make is to provide a working alternative, even if not
feature complete.

And this shouldn't take that long to do.
Rubygems was put together over a conference weekend, using
an existing code base.

I think an alternative could be put together quickly using RPA
and/or Ruby Gems as a code base.

--
Jim Freeze


 
Reply With Quote
 
Austin Ziegler
Guest
Posts: n/a
 
      11-20-2005
On 11/19/05, Andreas Schwarz <(E-Mail Removed)> wrote:
> halostatue wrote:
>> On 11/19/05, Trans <(E-Mail Removed)> wrote:
>>> So I'd like to know if others would be in support of this approach
>>> as I have already written a system to do exactly this.

> [...]
>> Yeah -- if you really want to propose an alternative, code it. No,
>> really. Sit down and code it out. Start finding out what the problems
>> with your approach would be. I'm *really* tired of people being lazy
>> backseat drivers to the problems that the RubyGems team has *solved*.

> Sometimes it could help to actually read the post you are replying to.


I did read. I will admit to having missed that. Trans would be better
off releasing his code rather than starting a pseudo-philsophical
discussion filled with his usual nonsense. If he thinks his approach is
better, he should just simply *release* the damned code rather than post
what he posted.

My prediction? People are going to find it far less useful and robust
than RubyGems and addressing a miniscule portion of the total problem
set.

>> Otherwise, STFU. Please.

> I think you have a problem with criticism.


I think you don't know me -- or don't really pay attention to the
projects on which I work. I have a problem with people who start
nonsense discussions, as Trans *often* does. He's not the only, but he
was one of the ones who was involved in one of the most nonsensical
discussions about Gems last time around.

For the record, I have never contributed code to RubyGems and have
equally supported RubyGems and RPA when both projects existed. Since no
one has actually bothered to release anything that they think is more
suitable than RubyGems that solves *both* problems that RubyGems solves
(and they'd *quickly* find out that the two pieces need to be closely
related), I have become a strong RubyGems advocate and have no time for
someone who isn't interested in a *clean* and *workable* Ruby-oriented
solution. RubyGems is not as clean as I'd like, but it's a lot cleaner
than Trans's so-called "solution."

-austin
--
Austin Ziegler * (E-Mail Removed)
* Alternate: (E-Mail Removed)


 
Reply With Quote
 
Lloyd Zusman
Guest
Posts: n/a
 
      11-20-2005
Austin Ziegler <(E-Mail Removed)> writes:

> On 11/19/05, Trans <(E-Mail Removed)> wrote:
>>
>> [ ... ]
>>
>> So I'd like to know if others would be in support of this approach as I
>> have already written a system to do exactly this. The system deals with
>> all the details that arise doding this and adds some additional
>> benefits, but the above is heart of the matter. The system is nearly
>> ready for release. I am down to completing thread safety and
>> solidifying the exact require interface that will support it.
>>
>> So what do you think? Anything you'd like me to clarify? Is there
>> support out there for pursuing this approach?

>
> Yeah -- if you really want to propose an alternative, code it. No,
> really. Sit down and code it out. Start finding out what the problems
> with your approach would be. I'm *really* tired of people being lazy
> backseat drivers to the problems that the RubyGems team has *solved*.
> If you don't like what RubyGems does, provide something else as a
> reasonable alternative.
>
> Otherwise, STFU. Please.


I'm not going to get involved in this discussion other than to make one
small point: Trans _has_ coded up an alternative. Re-read his paragraph
above (the one which starts with the words "So I'd like to know ...").


--
Lloyd Zusman
(E-Mail Removed)
God bless you.



 
Reply With Quote
 
Gregory Brown
Guest
Posts: n/a
 
      11-20-2005
On 11/19/05, Lloyd Zusman <(E-Mail Removed)> wrote:

> I'm not going to get involved in this discussion other than to make one
> small point: Trans _has_ coded up an alternative. Re-read his paragraph
> above (the one which starts with the words "So I'd like to know ...").


I am fully ignorant to the Gem issues, except for the latest annoying
issue with RubyForge and 1.8.3 / 1.8.4 gems.

So I certainly shouldn't pass judgement on who is right or wrong. =20
However, if Trans has coded something up, it would be a much more
powerful argument if we could actually see the code in action.


 
Reply With Quote
 
Lloyd Zusman
Guest
Posts: n/a
 
      11-20-2005
Gregory Brown <(E-Mail Removed)> writes:

> On 11/19/05, Lloyd Zusman <(E-Mail Removed)> wrote:
>
>> I'm not going to get involved in this discussion other than to make one
>> small point: Trans _has_ coded up an alternative. Re-read his paragraph
>> above (the one which starts with the words "So I'd like to know ...").

>
> I am fully ignorant to the Gem issues, except for the latest annoying
> issue with RubyForge and 1.8.3 / 1.8.4 gems.
>
> So I certainly shouldn't pass judgement on who is right or wrong.
> However, if Trans has coded something up, it would be a much more
> powerful argument if we could actually see the code in action.


As Trans mentioned, he is cleaning up that code and fully intends to
make it available. I think he gave a clear summary of his methodology,
and he asked for feedback. All that seems perfectly appropriate to me,
and I'm sure that we will soon be able to get our hands on the system
that he has created.

For the record, I like gems and use them a lot. I have had problems
with them in the past, but lately, I haven't had any major issues. This
is probably due to the fact that the code keeps getting updated and
improved.

Furthermore, I'm always willing to explore alternatives to the software
that I currently use, and therefore, I'm eager to take look at Trans'
system, when it becomes available.


--
Lloyd Zusman
(E-Mail Removed)
God bless you.



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Creating binary gems, from source gems Patrick Hurley Ruby 0 03-04-2007 09:47 PM
Problem getting gems/listing gems. EINVAL Thaddeus L Olczyk Ruby 0 08-15-2006 05:26 AM
Gems -- #include <gems.hpp> Tomás C++ 7 03-05-2006 02:48 PM
'private' gems/gems hierarchy Dany Cayouette Ruby 3 11-25-2005 10:55 PM
Confusion about gems and non-gems working together. Lloyd Zusman Ruby 3 06-20-2005 11:23 PM



Advertisments