gem remote installation does not work

Discussion in 'Ruby' started by Thomas Uehlinger, Aug 12, 2004.

  1. Hello

    I'm trying to remote install some gems, but i only get

    uehli@localhost uehli $ gem install --remote rake
    Attempting remote installation of 'rake'
    ERROR: While executing gem ... (Gem::GemNotFoundException)
    Could not find rake (> 0) in the repository


    I found out that 'gem' correctly downloads http://gems.rubyforge.org/yaml.Z,
    but fails afterwards.

    uehli@localhost uehli $ gem -v
    0.7.0
    uehli@localhost uehli $ ruby -v
    ruby 1.9.0 (2004-08-11) [i686-linux]


    Any ideas?

    -- Thomas Uehlinger
     
    Thomas Uehlinger, Aug 12, 2004
    #1
    1. Advertising

  2. On Thu, 12 Aug 2004 15:59:10 +0200
    Thomas Uehlinger <> wrote:

    > Any ideas?


    I know this is kinda the bad way to answer, since it involves installing
    a new package-system, but RPA is (IMHO) so much cooler than RubyGems.

    So you could go to: http://rpa-base.rubyforge.org and get the source,
    run the install.rb and do:
    rpa update # update pkg list
    rpa install rpa-base # update rpa itself
    rpa install rake # install rake

    Mmm... RPA... ;-)

    --
    Anders K. Madsen --- http://lillesvin.linux.dk

    "There are 10 types of people in the world.
    Those who understand binary - and those who don't."


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.5 (GNU/Linux)

    iD8DBQFBG3ralNHJe/JASHcRAgyqAJ0X/owa3X6BbHYeM7fZ+vr9jHh6OwCfYokd
    Yh9uoGsz+KBb1b5O6mBUnbg=
    =hN/D
    -----END PGP SIGNATURE-----
     
    Anders K. Madsen, Aug 12, 2004
    #2
    1. Advertising

  3. Thomas Uehlinger

    Chad Fowler Guest

    On Thu, 12 Aug 2004 23:01:11 +0900, Thomas Uehlinger
    <> wrote:
    > Hello
    >
    > I'm trying to remote install some gems, but i only get
    >
    > uehli@localhost uehli $ gem install --remote rake
    > Attempting remote installation of 'rake'
    > ERROR: While executing gem ... (Gem::GemNotFoundException)
    > Could not find rake (> 0) in the repository
    >
    > I found out that 'gem' correctly downloads http://gems.rubyforge.org/yaml.Z,
    > but fails afterwards.
    >
    > uehli@localhost uehli $ gem -v
    > 0.7.0
    > uehli@localhost uehli $ ruby -v
    > ruby 1.9.0 (2004-08-11) [i686-linux]
    >


    Hi Thomas.

    I'm not able to reproduce this problem, and I'm in a kind of limited
    environment in the office. My only guess is that it might be a
    problem with ruby 1.9.0. Do you have a 1.8.* build you could try it
    with? Otherwise, I can send you a patch later that will give us more
    information.

    Thanks,
    Chad
     
    Chad Fowler, Aug 12, 2004
    #3
  4. Thomas Uehlinger

    James Britt Guest

    Anders K. Madsen wrote:

    > On Thu, 12 Aug 2004 15:59:10 +0200
    > Thomas Uehlinger <> wrote:
    >
    >
    >>Any ideas?

    >
    >
    > I know this is kinda the bad way to answer, since it involves installing
    > a new package-system, but RPA is (IMHO) so much cooler than RubyGems.


    The RPA page says, "RPA will be a controlled repository of Ruby
    libraries and applications, managed by a dedicated team that will ensure
    consistency and proper QA."

    Does this mean that, if I want to release a library packaged for RPA, I
    would first need *permission*?

    The FAQ suggests that the actual developer cannot simply create an RPA
    package and release it. If that's true, it collides with my notion of
    "so much cooler."


    James
     
    James Britt, Aug 12, 2004
    #4
  5. On Fri, Aug 13, 2004 at 12:08:07AM +0900, James Britt wrote:
    > The RPA page says, "RPA will be a controlled repository of Ruby
    > libraries and applications, managed by a dedicated team that will ensure
    > consistency and proper QA."
    >
    > Does this mean that, if I want to release a library packaged for RPA, I
    > would first need *permission*?


    A qualified 'no', but read on...

    > The FAQ suggests that the actual developer cannot simply create an RPA
    > package and release it. If that's true, it collides with my notion of
    > "so much cooler."


    You can create packages/ports on your own, and release them without
    asking for any sort of approval/permission, either by distributing the
    rps files directly or by creating your own repository for rpa-base.

    It's fairly easy, but not really documented at this moment; see
    http://lillesvin.linux.dk/dyndnsupdate for an example.
    rpa-base (the package/port manager) allows it trivially with
    rpa install http://path/to/your-port.rps
    and also by defining additional 'non-official' repositories; in that case
    rpa install whatever
    would work directly, once the end-user has added your repository
    to the corresponding list (note however that I haven't exposed this
    capability at the UI level yet, but it will be implemented in some normal
    'self-update').

    However, I think there is some merit in having a controlled repository
    managed carefully: you can compare it to Debian's official repository
    vs. other non-official ones.

    In other words, you can distribute software for installation with
    rpa-base, but the primary goal of the project is RPA itself; rpa-base
    is but a means to reach it. Now, rpa-base does a number of interesting
    things (atomicity, ri/rdoc integration, etc), which might make it
    interesting for more general usages.

    I'm probably the one to blame for much of this confusion, due to the
    poor naming of the port/package manager. Here's a short explanation of
    some of the terms relative to RPA & friends:
    * RPA: Ruby Production Archive -> controlled repository containing a
    core section labelled as 'production software', which is to be managed
    according to stringent engineering practices. Note that this doesn't
    mean that other sw. cannot be packaged for RPA, but only that the
    primary goal of RPA is providing that 'stable core'. However, and to
    the extent that the resources at hand allow it, there is no reason
    for RPA not to make available a substantial number of
    libraries/packages, as a service to RPA users.
    * rpa-base: the port/package manager designed for RPA. It is fairly
    general and probably useful for other purposes, but that is not the
    main goal, which is being the technological support for RPA. In
    particular, it could be used in a decentralized way, very much like
    RubyGems, but that is not the main intended usage; you're free to use
    it any way you like, of course.
    * .rps: the ports (sources with a driver script for rpa-base) which are
    downloaded by rpa-base when installing something. Then binary packages
    (.rpa) are built using them.
    * .rpa: system-dependent binary packages, created from some port (.rps).
    These are generated during the installation phase, and will be used
    to set up binary repositories, eventually.

    I hope this clears it up. Don't hesitate to ask for additional
    explanations if there's something unclear; so far I've been rather
    unable to explain what RPA was because, well, I was busy making it
    happen (hacking rpa-base and maintaining over 100 packages does indeed
    take some time).

    --
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com
     
    Mauricio Fernández, Aug 12, 2004
    #5
  6. Thomas Uehlinger

    Jim Weirich Guest

    Thomas Uehlinger said:
    > Hello
    >
    > I'm trying to remote install some gems, but i only get
    >
    > uehli@localhost uehli $ gem install --remote rake
    > Attempting remote installation of 'rake'
    > ERROR: While executing gem ... (Gem::GemNotFoundException)
    > Could not find rake (> 0) in the repository
    >
    >
    > I found out that 'gem' correctly downloads
    > http://gems.rubyforge.org/yaml.Z,
    > but fails afterwards.
    >
    > uehli@localhost uehli $ gem -v
    > 0.7.0
    > uehli@localhost uehli $ ruby -v
    > ruby 1.9.0 (2004-08-11) [i686-linux]


    Hmmm... I've not tried gems on 1.9. That _could_ be the problem. I'll
    takek a closer look this evening.

    --
    -- 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, Aug 12, 2004
    #6
  7. Jim Weirich wrote:
    > Thomas Uehlinger said:
    >
    >>Hello
    >>
    >>I'm trying to remote install some gems, but i only get
    >>
    >>uehli@localhost uehli $ gem install --remote rake
    >>Attempting remote installation of 'rake'
    >>ERROR: While executing gem ... (Gem::GemNotFoundException)
    >> Could not find rake (> 0) in the repository
    >>
    >>
    >>I found out that 'gem' correctly downloads
    >>http://gems.rubyforge.org/yaml.Z,
    >>but fails afterwards.
    >>
    >>uehli@localhost uehli $ gem -v
    >>0.7.0
    >>uehli@localhost uehli $ ruby -v
    >>ruby 1.9.0 (2004-08-11) [i686-linux]

    >
    >
    > Hmmm... I've not tried gems on 1.9. That _could_ be the problem. I'll
    > takek a closer look this evening.
    >


    Yes, that could be. I found out that it works correctly on 1.8.1.

    -- Thomas
     
    Thomas Uehlinger, Aug 12, 2004
    #7
  8. Thomas Uehlinger

    Jim Weirich Guest

    Jim Weirich wrote:
    > Thomas Uehlinger said:
    >>I found out that 'gem' correctly downloads
    >>http://gems.rubyforge.org/yaml.Z,
    >>but fails afterwards.

    >
    > Hmmm... I've not tried gems on 1.9. That _could_ be the problem. I'll
    > takek a closer look this evening.


    Seems to be a YAML problem 1.9. I've sent a message to Why to confirm.
    I'll keep you updated.

    --
    -- 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, Aug 13, 2004
    #8
  9. Jim Weirich wrote:
    > Jim Weirich wrote:
    >
    >> Thomas Uehlinger said:
    >>
    >>> I found out that 'gem' correctly downloads
    >>> http://gems.rubyforge.org/yaml.Z,
    >>> but fails afterwards.

    >>
    >>
    >> Hmmm... I've not tried gems on 1.9. That _could_ be the problem. I'll
    >> takek a closer look this evening.

    >
    >
    > Seems to be a YAML problem 1.9. I've sent a message to Why to confirm.
    > I'll keep you updated.
    >


    With a 1.9 checkout from today it works. (in contrast to a checkout some
    days ago). This is probably due to the changes Why made lately.

    -- Thomas
     
    Thomas Uehlinger, Aug 13, 2004
    #9
  10. Thomas Uehlinger

    Chad Fowler Guest

    On Sat, 14 Aug 2004 04:16:06 +0900, Thomas Uehlinger
    <> wrote:
    > Jim Weirich wrote:
    > > Jim Weirich wrote:
    > >
    > >> Thomas Uehlinger said:
    > >>
    > >>> I found out that 'gem' correctly downloads
    > >>> http://gems.rubyforge.org/yaml.Z,
    > >>> but fails afterwards.
    > >>
    > >>
    > >> Hmmm... I've not tried gems on 1.9. That _could_ be the problem. I'll
    > >> takek a closer look this evening.

    > >
    > >
    > > Seems to be a YAML problem 1.9. I've sent a message to Why to confirm.
    > > I'll keep you updated.
    > >

    >
    > With a 1.9 checkout from today it works. (in contrast to a checkout some
    > days ago). This is probably due to the changes Why made lately.
    >



    Thanks for following up (and for your patience), Thomas.

    Chad
     
    Chad Fowler, Aug 13, 2004
    #10
  11. Mauricio Fernández <> writes:

    > You can create packages/ports on your own, and release them without
    > asking for any sort of approval/permission, either by distributing the
    > rps files directly or by creating your own repository for rpa-base.

    [...]
    > However, I think there is some merit in having a controlled repository
    > managed carefully: you can compare it to Debian's official repository
    > vs. other non-official ones.


    This is very important. The main reasons I like rpa are that it does
    all the housekeeping of package maintenance on my behalf and that it
    stays out of the way of the language and the interpreter (i.e. no
    special `require' forms to bring in modules).

    Ok, I also like automatic dependency resolution, file conflict
    detection, a certain flexibility in deciding where-goes-what, and
    transactions, but forgime me, I'm used to Debian and I've come to take
    those things for granted. :)

    Anyway, what you say above is important on a wider scale. QA and
    policy will help acceptance of Ruby in certain (e.g. corporate)
    contexts big time and goes beyond providing a means to install a piece
    of software quickly. Ultimately it is not different from the purpose
    of having a `standard distribution': ensuring a given set of packages
    is consistent and all parts interact nicely; by separating this task
    from that of maintining the basic interpreter parts I think both sides
    will benefit greatly.

    I've just a minor wishlist item for you. I've not tried building an
    rpa package (yet), so I don't know how the procedure goes, but I hope
    you've followed or will follow the adage `Everything should be made as
    simple as possible, but not simpler'. When I started learning
    building Debian packages, I was discouraged with the complexity
    (policy, helpers, and whatnot) when compared with e.g. rpms. As I
    went on, I was more and more grateful for it because it forced me to
    think hard and good about something that ultimately would happen on
    somebody else's computer. Which is a Good Thing.

    Massimiliano
     
    Massimiliano Mirra - bard, Aug 17, 2004
    #11
  12. On Wed, Aug 18, 2004 at 06:25:57AM +0900, Massimiliano Mirra - bard wrote:
    > This is very important. The main reasons I like rpa are that it does
    > all the housekeeping of package maintenance on my behalf and that it
    > stays out of the way of the language and the interpreter (i.e. no
    > special `require' forms to bring in modules).
    >
    > Ok, I also like automatic dependency resolution, file conflict
    > detection, a certain flexibility in deciding where-goes-what, and
    > transactions, but forgime me, I'm used to Debian and I've come to take
    > those things for granted. :)


    And many more goodies planned for 0.3.0 :))

    > Anyway, what you say above is important on a wider scale. QA and
    > policy will help acceptance of Ruby in certain (e.g. corporate)
    > contexts big time and goes beyond providing a means to install a piece
    > of software quickly. Ultimately it is not different from the purpose
    > of having a `standard distribution': ensuring a given set of packages
    > is consistent and all parts interact nicely; by separating this task
    > from that of maintining the basic interpreter parts I think both sides
    > will benefit greatly.


    I agree wholeheartedly.

    > I've just a minor wishlist item for you. I've not tried building an
    > rpa package (yet), so I don't know how the procedure goes, but I hope
    > you've followed or will follow the adage `Everything should be made as
    > simple as possible, but not simpler'. When I started learning
    > building Debian packages, I was discouraged with the complexity
    > (policy, helpers, and whatnot) when compared with e.g. rpms. As I


    Since I use Debian too, and create fairly reasonable Debian packages
    quite often, I can fully appreciate some of the benefits of its
    tools/methodology :) In particular, rpa-base uses "helpers" too (there's
    a list included in the sources actually), and the design is open to
    extension through additional helpers and refinement of the semantics of
    the current ones.

    I definitely want to have a RPA Policy.

    Note that some people have believed in the past that the latter would
    restrict what their sw. can do if they want it to be in RPA, or that
    they would be somehow forced to comply with the Policy. THIS IS NOT THE
    CASE. The Policy is but a set of (packaging, etc) rules RPA developers
    self-impose and decide to comply with. It is an effective tool to make
    sure the RPA system is consistent and high quality standards can be
    achieved. But it is not the goal of the RPA project to impose the RPA
    Policy to anybody else, or anything else for the matter.

    On a technical level, rpa-base has been designed to be open and avoid
    imposing its solutions to other systems.
    One example of this is the modified ri distributed via rpa-base as ri-rpa
    (for ri integration). This is clearly sub-optimal but was done that way
    to *avoid imposing* RPA-specific patches to Dave Thomas.

    > went on, I was more and more grateful for it because it forced me to
    > think hard and good about something that ultimately would happen on
    > somebody else's computer. Which is a Good Thing.


    --
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com
     
    Mauricio Fernández, Aug 18, 2004
    #12
  13. Mauricio Fernández <> writes:

    > Note that some people have believed in the past that the latter would
    > restrict what their sw. can do if they want it to be in RPA, or that
    > they would be somehow forced to comply with the Policy. THIS IS NOT THE
    > CASE.


    Speaking of taking Debian things for granted, it seems you simply did
    the same with the official/non-official concept. May I suggest you
    rename RPA as RPA/Official, and rpa-base as rpa-tool, or something
    along those lines, to clear up possible misunderstandings?

    Massimiliano
     
    Massimiliano Mirra - bard, Aug 18, 2004
    #13
  14. On Thu, Aug 19, 2004 at 06:21:16AM +0900, Massimiliano Mirra - bard wrote:
    > Mauricio Fernández <> writes:
    >
    > > Note that some people have believed in the past that the latter would
    > > restrict what their sw. can do if they want it to be in RPA, or that
    > > they would be somehow forced to comply with the Policy. THIS IS NOT THE
    > > CASE.

    >
    > Speaking of taking Debian things for granted, it seems you simply did
    > the same with the official/non-official concept. May I suggest you
    > rename RPA as RPA/Official, and rpa-base as rpa-tool, or something
    > along those lines, to clear up possible misunderstandings?


    I've been thinking about renaming rpa-base for some time; your
    suggestions sound good :) I'll ponder about it for a while, though...

    --
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com
     
    Mauricio Fernández, Aug 18, 2004
    #14
    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. Austin 7873
    Replies:
    5
    Views:
    190
    Eric Hodel
    Jan 27, 2007
  2. Markus Arike
    Replies:
    2
    Views:
    101
    Markus Arike
    Aug 19, 2008
  3. Forex Forex
    Replies:
    3
    Views:
    106
    Forex Forex
    Nov 7, 2008
  4. botp
    Replies:
    8
    Views:
    157
  5. Markus Fischer
    Replies:
    4
    Views:
    348
    Nick Klauer
    Mar 27, 2011
Loading...

Share This Page