An alternative to Gems

Ruby
1

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.

2

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.

3

On 11/19/05, Trans [email protected] 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

4

halostatue wrote:

On 11/19/05, Trans [email protected] 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.

5

On 11/19/05, Austin Z. [email protected] 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.

6

On 11/19/05, Austin Z. [email protected] wrote:

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

7

On 11/19/05, Andreas S. [email protected] wrote:

halostatue wrote:

On 11/19/05, Trans [email protected] 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

8

On 11/19/05, Lloyd Z. [email protected] 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.

9

Gregory B. [email protected] writes:

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.

10

Austin Z. [email protected] writes:

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 …”).

11

Austin Z. schrieb:

…
Otherwise, STFU. Please.

IIUC, Tom suggested to split support for versioning and packaging.
Separation of concerns is a well known method to decrease the complexity
of systems. Can you tell us why you think that in this case it would be
a bad idea?

Regards,
Pit

12

Pit C. wrote:

Not to discourage Austin from replying here, but the fairly recent
ruby-core archives should have a good run-down of the various positions
people have presented.

James

–

http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - Ruby Code & Style: Writers wanted
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools

13

James B. schrieb:

Pit C. wrote:

IIUC, Tom suggested to split support for versioning and packaging.
Separation of concerns is a well known method to decrease the
complexity of systems. Can you tell us why you think that in this case
it would be a bad idea?

Not to discourage Austin from replying here, but the fairly recent
ruby-core archives should have a good run-down of the various positions
people have presented.

(My memory is poor, so) I don’t remember pros and cons about splitting
versioning from packaging. Browsing through the archives I found LOTS of
discussions about a todo list for gems, support for other packaging
systems, even Nazis, and what not.

One argument against splitting I do remember is that we could have

Ruby + Gems(versioning and packaging)

sooner than

Ruby + Other(versioning) + Gems(packaging)

but this shouldn’t be enough to stop further discussions.

I don’t know much about those topics, so I’ll shut up now.

Regards,
Pit

14

IMHO, the acronym STFU doesn’t belong anywhere
near the Ruby community.

I agree. People here are nice, more than any other
programmer community I ever saw. I think we don’t need
this kind of thing.

Austin, I think you need to count to 10 (or more)
sometimes…

Perhaps to 1000. Or go watch a movie … a comedy,
please. :slight_smile:

Best regards,

15

Austin Z. wrote:

Otherwise, STFU. Please.

IMHO, the acronym STFU doesn’t belong anywhere
near the Ruby community.

Austin, I think you need to count to 10 (or more)
sometimes…

Later,

16

On 11/20/05, Pit C. [email protected] wrote:

IIUC, Tom suggested to split support for versioning and packaging.
Separation of concerns is a well known method to decrease the
complexity of systems. Can you tell us why you think that in this case
it would be a bad idea?

Separation of concerns is all fine and good when you’re dealing with
things that can be separated without increasing complexity. For
libraries, at least, I have come to the conclusion that you cannot
meaningfully separate packaging and versioning.

API versions are funny things. There should be language support for
selecting a particular API version. Given a promise that certain version
changes aren’t supposed to affect the API, you can even select the
latest version within a range of versions (RubyGems does this with the
~> version selector).

If you don’t have language support, then you’re often left hoping that
the user has the correct version installed or doesn’t upgrade. You can’t
effectively lock your needs to a single version.

If you can lock, then you either need packaging support for version
resolution (e.g., to encourage the installation of the required package
at install-time) or you’re again completely at the mercy of the user
not having installed the correct version and therefore being unable to
use your library or application at all.

You will still have problems when you need multiple versions of the same
API at the same time (e.g., sqlite_* and sqlite3_* in C/C++), but if
your library supports that sort of usage, that sort of thing should
probably be built into your namespacing techniques.

Package versions are often tightly tied to the API versions. If I need
version 1.2 of an API, I usually need version 1.2 of the package.

Packaging is not just the distribution format. It is also a way of
laying out files meaningfully after distribution. As has been discussed
on ruby-core, this does not just cover library layout, but data
layout, too. Two of my package currently have a data issue that RubyGems
allows me to solve semi-elegantly, but could be solved better in other
ways, I think. (This is not exclusively a RubyGems issue.)

Basically, we need core language support for versioning. Nothing that
Trans has proposed changes that. Indeed, he’s merely shuffled the
directory structure in a completely nonsensical way that decreases the
ability of packagers to uninstall programs and libraries. He will
still have to meaningfully make require use versioning. Ultimately,
he’s confusing the current less-than-optimal implementation of RubyGems
with what should be present when RubyGems is incorporated into the core
of Ruby.

I encourage Trans to release his code and encourage uptake. He won’t get
it unless he has a packaging format or packaging format support, and I
don’t see that happening, because he’s compounded, not simplified the
problems.

-austin

17

Ara.T.Howard schrieb:

On Sun, 20 Nov 2005, Austin Z. wrote:

Basically, we need core language support for versioning.

agreed.

Which is, as far as I understood, more or less what Tom proposed. A
quote from the original post:

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.

Thank you both, Austin and Ara, for the additional infos and the code
samples.

Regards,
Pit

18

Otherwise, STFU. Please.

I guess you could be a bit more polite :frowning:

-g.

19

On Sun, 20 Nov 2005, Austin Z. wrote:

> If you can lock, then you either need packaging support for version > resolution (e.g., to encourage the installation of the required package > at install-time) or you're again completely at the mercy of the user > *not* having installed the correct version and therefore being unable to > use your library or application at all.

it seems you are arguing for the existence of a linker. i agreet that
this is
needed - in fact i’ve written one for ruby! :wink: however, no linker
that i
know of has anything to do with the language itself and merely resolves
dependancies between units of code written in some language and, often,
expresses them by encodings in some sort of object file. assuming you
mean
something different by “language support” then, can you give a concrete
example of the kind you are suggesting?

Basically, we need core language support for versioning.

agreed.

i was asking for this in 2003 and designed the simplest possible
packaging
neutral version scheme i could think of:

see this thread:

 http://groups.google.com/group/comp.lang.ruby/browse_frm/thread/e01c5c9e6c83d26a/4962fe022ee266a2?q=howard+fsl+library+linker&rnum=1#4962fe022ee266a2

 http://www.codeforpeople.com//lib/ruby/library/library-0.0.0/doc/

of course rubygems now supports a similar scheme of adequate power and
i’m
using it several places (with the “~>” operator) to allow multi-versions
to
co-exist on production machines. it’s a powerful and, imho, totally,
100%,
completely, absolutely essential feature for using ruby in a production
environment. it’s wholly unacceptable to say

require “library”

and cross you fingers that you’ll be loading one that exports the
required
interfaces. further more it must be possible you have two, or more,
versions
of a library installed at once.

i manage about 50 packages on 100, or more machines and cannot imagine
having
to update all code using “library-0.0.0” when installing “library-1.0.0”

  • my
    approach has always been to install “library-1.0.0” in a way
    (versioning/linking) that only new applications will use it and, over
    time, to
    back port other codes to use the new library. however, for a short or
    long
    while both “library-0.0.0” and “library-1.0.0” must be able to
    peacefully
    co-exist on my systems. a selective versioning system is so critical i
    cannot understand how others get by without it - what do you others do?
    why
    is this ability not seen as paramount to be adopted into the language
    (via
    gems or some other mechanism) asap? i’d given up whining for it
    myself
    but this thread has given me hope that other people consider it as
    important
    as i do.

kind regards.

-a

20

Bil K. wrote:

Austin Z. wrote:

Otherwise, STFU. Please.

IMHO, the acronym STFU doesn’t belong anywhere near the Ruby
community.

Nor does IMHO for basically the same reason. Seriously, when is an
opinion humble? All it does is make you appear to not actually stand up
for what youâ??re about to say. So if you think Austin is being a dick
(you may want to choose your words better than I do) for telling someone
to shut the fuck up, then go ahead and say so. He can take it. Itâ??s
not the first time someoneâ??d think that heâ??s coming on too strong.

Still, this is just my humble opinion ;-).

    nikolai