Forum: Ruby An alternative to Gems

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
45196398e9685000d195ec626d477f0e?d=identicon&s=25 transfire (Guest)
on 2005-11-19 20:01
(Received via mailing list)
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.
Fee23d1fc58edee59e05d7a52dcf172e?d=identicon&s=25 blargity (Guest)
on 2005-11-19 20:14
(Received via mailing list)
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.
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 halostatue (Guest)
on 2005-11-19 22:48
(Received via mailing list)
On 11/19/05, Trans <transfire@gmail.com> 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
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 halostatue (Guest)
on 2005-11-19 22:48
(Received via mailing list)
On 11/19/05, Austin Ziegler <halostatue@gmail.com> 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
3a83969376c805ef5b6042191fdb0ff3?d=identicon&s=25 Andreas S. (andreas)
on 2005-11-19 23:05
halostatue wrote:
> On 11/19/05, Trans <transfire@gmail.com> 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.
8ecb8bb62c3283f8069a54056c7dc25f?d=identicon&s=25 jim (Guest)
on 2005-11-20 00:55
(Received via mailing list)
On 11/19/05, Austin Ziegler <halostatue@gmail.com> 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.
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 halostatue (Guest)
on 2005-11-20 01:07
(Received via mailing list)
On 11/19/05, Andreas Schwarz <f@andreas-s.net> wrote:
> halostatue wrote:
>> On 11/19/05, Trans <transfire@gmail.com> 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
56f2ce19706d05d18b5b66483aa13f98?d=identicon&s=25 ljz (Guest)
on 2005-11-20 01:15
(Received via mailing list)
Austin Ziegler <halostatue@gmail.com> 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 ...").
31e038e4e9330f6c75ccfd1fca8010ee?d=identicon&s=25 gregory.t.brown (Guest)
on 2005-11-20 01:59
(Received via mailing list)
On 11/19/05, Lloyd Zusman <ljz@asfast.com> 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.
56f2ce19706d05d18b5b66483aa13f98?d=identicon&s=25 ljz (Guest)
on 2005-11-20 02:24
(Received via mailing list)
Gregory Brown <gregory.t.brown@gmail.com> 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.
93d566cc26b230c553c197c4cd8ac6e4?d=identicon&s=25 pit (Guest)
on 2005-11-20 07:58
(Received via mailing list)
Austin Ziegler 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
Bc6d88907ce09158581fbb9b469a35a3?d=identicon&s=25 james_b (Guest)
on 2005-11-20 08:26
(Received via mailing list)
Pit Capitain 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
http://www.artima.com/rubycs/ - 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
93d566cc26b230c553c197c4cd8ac6e4?d=identicon&s=25 pit (Guest)
on 2005-11-20 09:02
(Received via mailing list)
James Britt schrieb:
> Pit Capitain 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
A87f7a014c624587fab0d3d78c5b9c18?d=identicon&s=25 Bil.Kleb (Guest)
on 2005-11-20 14:20
(Received via mailing list)
Austin Ziegler 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,
C63e105d68d1e5e8dcba755d15de7a22?d=identicon&s=25 eustaquiorangel (Guest)
on 2005-11-20 15:20
(Received via mailing list)
> 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. :-)

Best regards,
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 halostatue (Guest)
on 2005-11-20 15:40
(Received via mailing list)
On 11/20/05, Pit Capitain <pit@capitain.de> 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
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 ara.t.howard (Guest)
on 2005-11-20 16:12
(Received via mailing list)
On Sun, 20 Nov 2005, Austin Ziegler wrote:

<snip>
> 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.
<snip>

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!  ;-)  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.
<snip>

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/brow...

     http://www.codeforpeople.com//lib/ruby/library/lib...


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
93d566cc26b230c553c197c4cd8ac6e4?d=identicon&s=25 pit (Guest)
on 2005-11-20 16:52
(Received via mailing list)
Ara.T.Howard schrieb:
> On Sun, 20 Nov 2005, Austin Ziegler 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
7a4e995e378ef66de0ceaea5e1381ee1?d=identicon&s=25 george.moschovitis (Guest)
on 2005-11-20 17:54
(Received via mailing list)
>
> Otherwise, STFU. Please.

I guess you could be a bit more polite :(

-g.
D1c54205b0ba8f40cbb774c6bc557376?d=identicon&s=25 mailing-lists.ruby-talk (Guest)
on 2005-11-20 19:34
(Received via mailing list)
Bil Kleb wrote:

> Austin Ziegler 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
A87f7a014c624587fab0d3d78c5b9c18?d=identicon&s=25 Bil.Kleb (Guest)
on 2005-11-20 19:50
(Received via mailing list)
Nikolai Weibull wrote:
>
> Nor does IMHO for basically the same reason.

For whatever reason, I don't view IMHO as inflammatory
as STFU, YMMV.  :)

> Seriously, when is an opinion humble?

Sometimes, I think "honest" instead of "humble", sorry
for the confusion.
31ab75f7ddda241830659630746cdd3a?d=identicon&s=25 halostatue (Guest)
on 2005-11-20 22:23
(Received via mailing list)
On 11/20/05, Pit Capitain <pit@capitain.de> wrote:
> Thank you both, Austin and Ara, for the additional infos and the code
> samples.

Except that Trans has taken an irrational dislike to the way that
RubyGems does this and has proposed something that is even *less*
usable and is conceptually bankrupt. Frankly, I tire of the
nonsensical whimsical proposals that have no application in the real
world. I want him to put up this time, because every other critic of
RubyGems so far has failed to do so in any way that solves the twin
problems.

I still maintain that packaging and versioning belong together.

-austin
D1c54205b0ba8f40cbb774c6bc557376?d=identicon&s=25 mailing-lists.ruby-talk (Guest)
on 2005-11-21 01:16
(Received via mailing list)
Bil Kleb wrote:

> Nikolai Weibull wrote:

> > Nor does IMHO for basically the same reason.

> For whatever reason, I don't view IMHO as inflammatory as STFU, YMMV.
> :)

Yeah, I was just being a bit silly (and you seem to have picked up on
that ;-).

> > Seriously, when is an opinion humble?

> Sometimes, I think "honest" instead of "humble", sorry for the
> confusion.

No problem, but I guess that's a good reason for not using
abbreviations.  Anyway, I'll take an honest opinion over a humble one
any day.

> --
> Bil
> Born in Aurora, IL; currently residing in Yorktown, VA

;-D

        nikolai
This topic is locked and can not be replied to.