Confusion about gems and non-gems working together.

Discussion in 'Ruby' started by Lloyd Zusman, Jun 17, 2005.

  1. Lloyd Zusman

    Lloyd Zusman Guest

    Ever since I started installing packages via the gems mechanism, I have
    kept running into problems that few others seemed to have (or at least
    mention here). More often than I would like, a gem installation would
    either fail outright, or else it would get installed but not work
    properly, yielding errors that seemed to be non-reproducible by others.

    I now think that I might have figured out what is going on for me:

    In all the cases where I had these problems, I had non-gem installs of
    earlier versions of the packages. In many cases, it seems like code
    inside of files associated with these earlier versions would get
    executed instead of the code that the newer gem would use.

    I have a standard ruby installation with no special path settings, and
    yet, I still am getting these unwanted interactions between certain gems
    and their older, non-gem counterparts.

    Has anyone else experienced anything like this? If so, how did you
    handle it?

    I presume that when I install a gem, I should completely uninstall any
    older, non-gem versions of the same package. What is the accepted way
    to uninstall a package? Do I just go into the ruby tree and delete all
    files and directories associated with the non-gem? If so, how can I
    find out what is the exhaustive list of files and directories to remove
    for a given package?

    This brings up a suggestion: could the gem installer check for
    previously installed non-gem versions of the package in question, and
    then ask the user if he/she wants to optionally delete them as part of
    the gem install? Something like that would be massively useful, IMHO.


    --
    Lloyd Zusman

    God bless you.
     
    Lloyd Zusman, Jun 17, 2005
    #1
    1. Advertising

  2. Lloyd Zusman

    Chad Fowler Guest

    Hi Lloyd!

    On 6/17/05, Lloyd Zusman <> wrote:
    > Ever since I started installing packages via the gems mechanism, I have
    > kept running into problems that few others seemed to have (or at least
    > mention here). More often than I would like, a gem installation would
    > either fail outright, or else it would get installed but not work
    > properly, yielding errors that seemed to be non-reproducible by others.
    >=20
    > I now think that I might have figured out what is going on for me:
    >=20
    > In all the cases where I had these problems, I had non-gem installs of
    > earlier versions of the packages. In many cases, it seems like code
    > inside of files associated with these earlier versions would get
    > executed instead of the code that the newer gem would use.
    >=20
    > I have a standard ruby installation with no special path settings, and
    > yet, I still am getting these unwanted interactions between certain gems
    > and their older, non-gem counterparts.
    >=20
    > Has anyone else experienced anything like this? If so, how did you
    > handle it?
    >=20


    I haven't, but I don't use non-gem libs much anymore. Could you give a spe=
    cific
    example? I think it might be instructive. As long as the gem version
    of the library
    is before the non-gem version in the load path (which it should be), you sh=
    ould
    get the gem version of the lib. Since that's obviously not the way
    it's working for you, it would be great to hear some specifics.

    > I presume that when I install a gem, I should completely uninstall any
    > older, non-gem versions of the same package. What is the accepted way
    > to uninstall a package? Do I just go into the ruby tree and delete all
    > files and directories associated with the non-gem? If so, how can I
    > find out what is the exhaustive list of files and directories to remove
    > for a given package?
    >=20


    That's part of the problem pre-gems. There's no nice, repeatable way
    to do this. If you've got the original tar file lying around, you can
    look at it's contents and remove files that seem to have been
    installed by it. Even then, you'll probably want to use a checksum of
    some sort just in case installations of later libs over wrote files of
    the same name (which you might still be depending on).

    > This brings up a suggestion: could the gem installer check for
    > previously installed non-gem versions of the package in question, and
    > then ask the user if he/she wants to optionally delete them as part of
    > the gem install? Something like that would be massively useful, IMHO.
    >=20


    I'll add it to our list. It would be hard to do cleanly and reliably,
    but as an optional user-verifiable setting, it wouldn't be too
    terribly evil.


    >=20
    > --
    > Lloyd Zusman
    >
    > God bless you.
    >=20
    >=20
    >=20



    --=20

    Chad Fowler
    http://chadfowler.com
    http://rubycentral.org=20
    http://rubygarden.org=20
    http://rubygems.rubyforge.org (over 300,000 gems served!)
     
    Chad Fowler, Jun 18, 2005
    #2
    1. Advertising

  3. Lloyd Zusman

    Jim Weirich Guest

    On Saturday 18 June 2005 04:10 pm, Chad Fowler wrote:
    > > In all the cases where I had these problems, I had non-gem installs of
    > > earlier versions of the packages. In many cases, it seems like code
    > > inside of files associated with these earlier versions would get
    > > executed instead of the code that the newer gem would use.
    > > [...]
    > > Has anyone else experienced anything like this? If so, how did you
    > > handle it?

    >
    > I haven't, but I don't use non-gem libs much anymore. [...]
    > As long as the gem version of the library
    > is before the non-gem version in the load path (which it should be), you
    > should get the gem version of the lib.


    If no explicit require_gem is done on the library, then the non-gem version
    will take precedence. If there is no non-gem version, or an explicit
    require_gem has requested the library, then the gem version will be used.

    --
    -- Jim Weirich http://onestepback.org
    -----------------------------------------------------------------
    "Beware of bugs in the above code; I have only proved it correct,
    not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
     
    Jim Weirich, Jun 19, 2005
    #3
  4. Lloyd Zusman

    Lloyd Zusman Guest

    Chad Fowler <> writes:

    > Hi Lloyd!


    Hi Chad! :)


    > [ ... ]
    >
    >> I now think that I might have figured out what is going on for me:
    >>
    >> In all the cases where I had these problems, I had non-gem installs of
    >> earlier versions of the packages. In many cases, it seems like code
    >> inside of files associated with these earlier versions would get
    >> executed instead of the code that the newer gem would use.
    >>
    >> [ ... ]
    >>
    >> Has anyone else experienced anything like this? If so, how did you
    >> handle it?
    >>

    >
    > I haven't, but I don't use non-gem libs much anymore. Could you give
    > a specific example? I think it might be instructive. As long as the
    > gem version of the library is before the non-gem version in the load
    > path (which it should be), you should get the gem version of the lib.
    > Since that's obviously not the way it's working for you, it would be
    > great to hear some specifics.


    Well, prior to receiving this message of yours, I had fixed all
    occurrences of this problem by manually deleting the non-gem versions of
    the offending packages. Therefore, it's hard to reproduce now.

    However, one case I recall clearly where I had consistent problems was
    when I first installed the gem version of wee. I had installed an
    earlier non-gem version, and until I deleted that, I couldn't even get
    the gem install to work. My messages about this problem should be in
    the archives of this mailing list, although that was before I thought of
    the possibility that the non-gem version might be interfering with the
    gem.


    >> [ ... ] If so, how can I find out what is the exhaustive list of
    >> files and directories to remove for a given package?
    >>

    >
    > That's part of the problem pre-gems. There's no nice, repeatable way
    > to do this. If you've got the original tar file lying around, you can
    > look at it's contents and remove files that seem to have been
    > installed by it. [ ... ]


    Yes, that's what I have done during the manual uninstalls that I
    mentioned above.

    > [ ... ] Even then, you'll probably want to use a checksum of some
    > sort just in case installations of later libs over wrote files of the
    > same name (which you might still be depending on).


    I didn't do that in this case. I hope I don't get bit.


    >> This brings up a suggestion: could the gem installer check for
    >> previously installed non-gem versions of the package in question, and
    >> then ask the user if he/she wants to optionally delete them as part of
    >> the gem install? [ ... ]
    >>

    >
    > I'll add it to our list. It would be hard to do cleanly and reliably,
    > but as an optional user-verifiable setting, it wouldn't be too
    > terribly evil.


    As I mentioned earlier, I would find it amply useful, and I'm sure that
    I'm not the only person.


    --
    Lloyd Zusman

    God bless you.
     
    Lloyd Zusman, Jun 21, 2005
    #4
    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. phil cunningham
    Replies:
    2
    Views:
    408
    Rob R. Ainscough
    Jan 25, 2006
  2. Rod
    Replies:
    0
    Views:
    427
  3. hiwa
    Replies:
    3
    Views:
    1,027
  4. R
    Replies:
    0
    Views:
    730
  5. Christian Graf
    Replies:
    2
    Views:
    407
Loading...

Share This Page