An alternative to Gems

Discussion in 'Ruby' started by Trans, Nov 19, 2005.

  1. Trans

    Trans Guest

    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.
     
    Trans, Nov 19, 2005
    #1
    1. Advertising

  2. Trans

    Kevin Brown Guest

    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.
     
    Kevin Brown, Nov 19, 2005
    #2
    1. Advertising

  3. On 11/19/05, Trans <> 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 *
    * Alternate:
     
    Austin Ziegler, Nov 19, 2005
    #3
  4. On 11/19/05, Austin Ziegler <> wrote:
    > On 11/19/05, Trans <> 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 *
    * Alternate:
     
    Austin Ziegler, Nov 19, 2005
    #4
  5. halostatue wrote:
    > On 11/19/05, Trans <> 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/.
     
    Andreas Schwarz, Nov 19, 2005
    #5
  6. Trans

    Jim Freeze Guest

    On 11/19/05, Austin Ziegler <> 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
     
    Jim Freeze, Nov 19, 2005
    #6
  7. On 11/19/05, Andreas Schwarz <> wrote:
    > halostatue wrote:
    >> On 11/19/05, Trans <> 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 *
    * Alternate:
     
    Austin Ziegler, Nov 20, 2005
    #7
  8. Trans

    Lloyd Zusman Guest

    Austin Ziegler <> writes:

    > On 11/19/05, Trans <> 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

    God bless you.
     
    Lloyd Zusman, Nov 20, 2005
    #8
  9. On 11/19/05, Lloyd Zusman <> 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.
     
    Gregory Brown, Nov 20, 2005
    #9
  10. Trans

    Lloyd Zusman Guest

    Gregory Brown <> writes:

    > On 11/19/05, Lloyd Zusman <> 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

    God bless you.
     
    Lloyd Zusman, Nov 20, 2005
    #10
  11. Trans

    Pit Capitain Guest

    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
     
    Pit Capitain, Nov 20, 2005
    #11
  12. Trans

    James Britt Guest

    Pit Capitain wrote:
    > 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?
    >


    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
     
    James Britt, Nov 20, 2005
    #12
  13. Trans

    Pit Capitain Guest

    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
     
    Pit Capitain, Nov 20, 2005
    #13
  14. Trans

    Bil Kleb Guest

    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,
    --
    Bil
    http://fun3d.larc.nasa.gov
     
    Bil Kleb, Nov 20, 2005
    #14
  15. > 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.
    =20
    > 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,

    ----------------------------
    Eust=E1quio "TaQ" Rangel=20

    http://beam.to/taq=20
    Usu=E1rio GNU/Linux no. 224050
     
    Eustaquio Rangel de Oliveira J, Nov 20, 2005
    #15
  16. On 11/20/05, 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?


    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
    --
    Austin Ziegler *
    * Alternate:
     
    Austin Ziegler, Nov 20, 2005
    #16
  17. Trans

    Ara.T.Howard Guest

    On Sun, 20 Nov 2005, Austin Ziegler wrote:

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

    <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...rd 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
    --
    ===============================================================================
    | ara [dot] t [dot] howard [at] gmail [dot] com
    | all happiness comes from the desire for others to be happy. all misery
    | comes from the desire for oneself to be happy.
    | -- bodhicaryavatara
    ===============================================================================
     
    Ara.T.Howard, Nov 20, 2005
    #17
  18. Trans

    Pit Capitain Guest

    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
     
    Pit Capitain, Nov 20, 2005
    #18
  19. George Moschovitis, Nov 20, 2005
    #19
  20. 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=E2=80=99re 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 **** up, then go ahead and say so. He can take it. It=E2=80=
    =99s
    not the first time someone=E2=80=99d think that he=E2=80=99s coming on to=
    o strong.

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

    nikolai

    --=20
    Nikolai Weibull: now available free of charge at http://bitwi.se/!
    Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
    main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}
     
    Nikolai Weibull, Nov 20, 2005
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tomás

    Gems -- #include <gems.hpp>

    Tomás, Mar 4, 2006, in forum: C++
    Replies:
    7
    Views:
    426
    Tomás
    Mar 5, 2006
  2. Lloyd Zusman
    Replies:
    3
    Views:
    185
    Lloyd Zusman
    Jun 21, 2005
  3. Dany Cayouette

    'private' gems/gems hierarchy

    Dany Cayouette, Nov 25, 2005, in forum: Ruby
    Replies:
    3
    Views:
    159
    Jim Weirich
    Nov 25, 2005
  4. Thaddeus L Olczyk

    Problem getting gems/listing gems. EINVAL

    Thaddeus L Olczyk, Aug 15, 2006, in forum: Ruby
    Replies:
    0
    Views:
    193
    Thaddeus L Olczyk
    Aug 15, 2006
  5. Patrick Hurley

    Creating binary gems, from source gems

    Patrick Hurley, Mar 4, 2007, in forum: Ruby
    Replies:
    0
    Views:
    139
    Patrick Hurley
    Mar 4, 2007
Loading...

Share This Page