From drbrain at segment7.net Fri Feb 1 05:22:25 2008 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 1 Feb 2008 02:22:25 -0800 Subject: [Rubygems-developers] WARNINGS In-Reply-To: References: <87AE92A5-A3E4-4531-8A2A-46B0588171EA@segment7.net> Message-ID: <809941D6-7A54-406B-A47C-9657E154B799@segment7.net> On Jan 31, 2008, at 17:33 PM, Mark Hubbart wrote: > On Jan 31, 2008 2:23 PM, Eric Hodel wrote: >> On Jan 30, 2008, at 13:10 PM, Trans wrote: >>> On Jan 30, 12:48 pm, "Luis Lavena" wrote: >>>> On Jan 30, 2008 3:43 PM, Trans wrote: >>>>> Why is Rubygems now issuing warnings when building, eg. >>>> >>>>> WARNING: no rubyforge_project specified >>>>> WARNING: RDoc will not be generated (has_rdoc == false) >>>> >>>>> I've never seen it do this before. How to I silence it? (Using >>>>> ruby, >>>>> not command line). >>>> >>>> These warnings where introduced due bad gem specifications. >>>> >> >>>> Setting the correct values in the gem specification will silent >>>> these warnings. >>> >>> That's not so. The has_rdoc is set to false for a reason. >> >> Then you're a bad person. Not generating RDoc/ri is hostile to your >> users. > > harsh much? No. Little is more annoying than running `gem server` or `ri` when I'm stuck on a problem and finding out that I have to trudge through source to figure out how to use a library because the author decided to deny me even the luxury of a class and method list. > Reasons you might not want to generate RDoc for a particular gem: > > - Your interface is already documented. Say you write a lib that > speeds up the use of Ruby's built-in complex class. If there's nothing > but a speed improvement, why re-document the methods? > - There is no interface to document. Perhaps your library does magic > stuff in the background (say, logging performance stats), needing no > method calls whatsoever. There isn't even have a README? That's hostile. > - Your entire interface is dynamic, and has no set method calls. Maybe > you prefer to explain it on a website. Then I need an internet connection. I don't always have one. Also hostile. > - Some other reason, at the choice of the developer. Complain to them > if they're wrong. RubyGems is complaining to the developer in the form of a warning. > Anyway, if it's always bad to not generate rdoc/ri, they should simply > take the flag out. Which is why it warns, but does not force generation of RDoc. >>> Plus one might not have a rubyforge project. >> >> There's an "orphans" project on rubyforge for gems that are lacking a >> real project. If you're building an internal gem, I think you can >> deal with it. > > The "real" project could be on sourceforge.org, or code.google.com. So you get a warning. > But if a project name is that important, maybe rubygems should insert > the default one (the "orphans" project) whenever none is specified. This would be wrong, since the gem may never show up on rubyforge. > Anyway, it seems like these warnings should be given when building the > gem, not while installing it. These warnings are not generated at install time. From hgs at dmu.ac.uk Fri Feb 1 05:23:41 2008 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Fri, 1 Feb 2008 10:23:41 +0000 (WET) Subject: [Rubygems-developers] WARNINGS In-Reply-To: References: <87AE92A5-A3E4-4531-8A2A-46B0588171EA@segment7.net> Message-ID: On Thu, 31 Jan 2008, Mark Hubbart wrote: > > On Jan 31, 2008 2:23 PM, Eric Hodel wrote: [...] > > > On Jan 30, 2008, at 13:10 PM, Trans wrote: > > > > > > > > That's not so. The has_rdoc is set to false for a reason. > > > > > > Then you're a bad person. Not generating RDoc/ri is hostile to your > > > users. > > harsh much? Could have done with an emoticon, but the context implies jocular. > > Reasons you might not want to generate RDoc for a particular gem: > > - Your interface is already documented. Say you write a lib that > speeds up the use of Ruby's built-in complex class. If there's nothing > but a speed improvement, why re-document the methods? why not use :nodoc: ? > - There is no interface to document. Perhaps your library does magic > stuff in the background (say, logging performance stats), needing no > method calls whatsoever. > - Your entire interface is dynamic, and has no set method calls. Maybe > you prefer to explain it on a website. Not sure how to apply :nodoc: in these cases. [...] > > > Plus one might not have a rubyforge project. > > [...] > The "real" project could be on sourceforge.org, or code.google.com. Maybe there needs to a directive to say whwere the project is? Hugh From drbrain at segment7.net Fri Feb 1 06:22:07 2008 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 1 Feb 2008 03:22:07 -0800 Subject: [Rubygems-developers] WARNINGS In-Reply-To: References: <87AE92A5-A3E4-4531-8A2A-46B0588171EA@segment7.net> Message-ID: <9CBDAE81-2D39-4632-BDC9-1E34C64B4DAA@segment7.net> On Feb 1, 2008, at 02:23 AM, Hugh Sasse wrote: > On Thu, 31 Jan 2008, Mark Hubbart wrote: >>>> Plus one might not have a rubyforge project. >>> > [...] >> The "real" project could be on sourceforge.org, or code.google.com. > > Maybe there needs to a directive to say whwere the project is? There is also a #homepage= for Gem::Specification, but with the current gem repository, this is a bikeshed objection as under 1% of gems are published without a rubyforge project. From hgs at dmu.ac.uk Fri Feb 1 07:02:00 2008 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Fri, 1 Feb 2008 12:02:00 +0000 (WET) Subject: [Rubygems-developers] WARNINGS In-Reply-To: <9CBDAE81-2D39-4632-BDC9-1E34C64B4DAA@segment7.net> References: <87AE92A5-A3E4-4531-8A2A-46B0588171EA@segment7.net> <9CBDAE81-2D39-4632-BDC9-1E34C64B4DAA@segment7.net> Message-ID: On Fri, 1 Feb 2008, Eric Hodel wrote: > On Feb 1, 2008, at 02:23 AM, Hugh Sasse wrote: > > On Thu, 31 Jan 2008, Mark Hubbart wrote: > >>>> Plus one might not have a rubyforge project. > >>> > > [...] > >> The "real" project could be on sourceforge.org, or code.google.com. > > > > Maybe there needs to a directive to say whwere the project is? > > There is also a #homepage= for Gem::Specification, but with the > current gem repository, this is a bikeshed objection as under 1% of > gems are published without a rubyforge project. I'd agree the default is correct most of the time, but there are a lot of gems now, so 1% is not insignificant. I don't see that arguing for choice is a bikeshed argument. If you argue that too much code will have to change to support this, that it is the thin end of a long wedge (multiple mirror sites will come next!) that it would make the gemspec more brittle as it depends on more information, or that the suggestion is otherwise malformed, then fair enough. It was a suggestion offered in the hope that someone might say "I have a better idea:...". Is there a wishlist to which this might be added? Maybe *I'm* taking your use of the word "bikeshed" too seriously! I'm really only trying to help suggest a "fix" for a known edge case, I'm not saying things are fundamentally wrong, because clearly gems have been marvellous for ages. Hugh From drbrain at segment7.net Fri Feb 1 07:21:13 2008 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 1 Feb 2008 04:21:13 -0800 Subject: [Rubygems-developers] WARNINGS In-Reply-To: References: <87AE92A5-A3E4-4531-8A2A-46B0588171EA@segment7.net> <9CBDAE81-2D39-4632-BDC9-1E34C64B4DAA@segment7.net> Message-ID: On Feb 1, 2008, at 04:02 AM, Hugh Sasse wrote: > On Fri, 1 Feb 2008, Eric Hodel wrote: >> On Feb 1, 2008, at 02:23 AM, Hugh Sasse wrote: >>> On Thu, 31 Jan 2008, Mark Hubbart wrote: >>>>>> Plus one might not have a rubyforge project. >>>>> >>> [...] >>>> The "real" project could be on sourceforge.org, or code.google.com. >>> >>> Maybe there needs to a directive to say whwere the project is? >> >> There is also a #homepage= for Gem::Specification, but with the >> current gem repository, this is a bikeshed objection as under 1% of >> gems are published without a rubyforge project. > > I'd agree the default is correct most of the time, but there are a > lot of gems now, so 1% is not insignificant. I don't see that > arguing for choice is a bikeshed argument. If you argue that too > much code will have to change to support this, that it is the thin > end of a long wedge (multiple mirror sites will come next!) that it > would make the gemspec more brittle as it depends on more > information, or that the suggestion is otherwise malformed, then > fair enough. It was a suggestion offered in the hope that someone > might say "I have a better idea:...". Is there a wishlist to which > this might be added? Maybe *I'm* taking your use of the word > "bikeshed" too seriously! I'm really only trying to help suggest a > "fix" for a known edge case, I'm not saying things are fundamentally > wrong, because clearly gems have been marvellous for ages. I say it's a bikeshed argument as it only affects gem authors who don't publish on rubyforge, and none of them have complained about it, and people are complaining for such a person who might exist, maybe. I've asked Tom for the number of gems that are added to the repository manually, just to be sure. From hgs at dmu.ac.uk Fri Feb 1 08:13:45 2008 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Fri, 1 Feb 2008 13:13:45 +0000 (WET) Subject: [Rubygems-developers] WARNINGS In-Reply-To: References: <87AE92A5-A3E4-4531-8A2A-46B0588171EA@segment7.net> <9CBDAE81-2D39-4632-BDC9-1E34C64B4DAA@segment7.net>

Message-ID: On Fri, 1 Feb 2008, Eric Hodel wrote: > I say it's a bikeshed argument as it only affects gem authors who > don't publish on rubyforge, and none of them have complained about it, OK, then it's more 'YAGNI' than 'bikeshed', but I concede all the same. > and people are complaining for such a person who might exist, maybe. > > I've asked Tom for the number of gems that are added to the repository > manually, just to be sure. Thanks. Hugh From transfire at gmail.com Fri Feb 1 08:45:22 2008 From: transfire at gmail.com (Trans) Date: Fri, 1 Feb 2008 05:45:22 -0800 (PST) Subject: [Rubygems-developers] WARNINGS In-Reply-To: <809941D6-7A54-406B-A47C-9657E154B799@segment7.net> References: <87AE92A5-A3E4-4531-8A2A-46B0588171EA@segment7.net> <809941D6-7A54-406B-A47C-9657E154B799@segment7.net> Message-ID: On Feb 1, 5:22 am, Eric Hodel wrote: > So you get a warning. Is there a means for suppressing the warnings? If not could you add one --check $VERBOSE, for instance? Actually, a way to suppress the entire output would be nice. A number of people have created secondary tools for generating gems (eg. GemPackageTask), it would be nice to have control over the output of that process. Thanks, T. From tom at infoether.com Fri Feb 1 09:18:05 2008 From: tom at infoether.com (Tom Copeland) Date: Fri, 01 Feb 2008 09:18:05 -0500 Subject: [Rubygems-developers] WARNINGS In-Reply-To: References: <87AE92A5-A3E4-4531-8A2A-46B0588171EA@segment7.net> <9CBDAE81-2D39-4632-BDC9-1E34C64B4DAA@segment7.net>

Message-ID: <1201875485.9695.19.camel@bugs.hal> On Fri, 2008-02-01 at 04:21 -0800, Eric Hodel wrote: > I've asked Tom for the number of gems that are added to the repository > manually, just to be sure. Not very many... I can't remember the last time that happened. But yup, the orphans project would be a good place for that, although: http://rubyforge.org/frs/?group_id=4069 Slim pickins so far... Yours, Tom From hgs at dmu.ac.uk Fri Feb 1 09:23:56 2008 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Fri, 1 Feb 2008 14:23:56 +0000 (WET) Subject: [Rubygems-developers] WARNINGS In-Reply-To: References: <87AE92A5-A3E4-4531-8A2A-46B0588171EA@segment7.net> <809941D6-7A54-406B-A47C-9657E154B799@segment7.net> Message-ID: On Fri, 1 Feb 2008, Trans wrote: > Actually, a way to suppress the entire output would be nice. A number In the meantime an expect wrapper might do the trick. Just 2 more wafer thin dependencies, Tcl, Expect. Hugh From me at susanpotter.net Fri Feb 1 10:17:38 2008 From: me at susanpotter.net (Susan Potter) Date: Fri, 1 Feb 2008 09:17:38 -0600 Subject: [Rubygems-developers] RubyGems Dependency Type In-Reply-To: References: <1076b0d90801301032hb5ba5d1qf93d5287172d3a21@mail.gmail.com> Message-ID: <1076b0d90802010717r587b5901k43a539723590fa49@mail.gmail.com> Chad, Thanks very much for responding. Your suggestions are great. The internal gem was tailored to the client development environment/philosophy, so you made some good points that I either hadn't thought of before or weren't relevant in our specific client context. > Anyway, I think this sounds like a very reasonable proposal. Couple > of comments/suggestions, though: > > 1. Preserving backward compatablity and default behavior for existing > gems/specs/dependencies is of utmost importance. Functional sanity > check tests which automatically run against existing gems/specs from > rubyforge, and ensure that dependencies are still handled the same, > would be a good regression safety net. Great point. Internally I just had to make sure internal clients were satisfied, so I will refer to the tests and code of RubyGems to appreciate better the current logic. This is a good place for me to start before changing/adding any code. > 2. What is the -D switch to install short for? Naming is important - > maybe -T/--type? or -c/--category? I kind of like category, not too > generic, not an overloaded term. I have have no problem to change the naming. -D/--dependency-type was in our internal gem we used as a gem CLI wrapper, but frankly I am more interested in providing a way to describe this in metadata than worrying about the CLI argument naming myself and -c/--category appears like a better fit for a more general setting. > 3. The area that will cause the most contention is probably the > default categories. You suggested 'runtime', 'test', and 'compile'. > 'runtime' and 'test' sound reasonable, but what is compile? Are these > for platform-specific build dependencies? What about build-time only > (non-runtime) dependencies for pure-ruby gems? Maybe 'build' would be > a more generic choice than 'compile'. Also, what about deploy- or > publish-time dependencies - such as hoe, rubyforge, webgen/webby, etc? > Are these in the 'build' category as well? I have no problem changing the names of the "categories" at all. Using 'build' instead of 'compile' sounds like a good idea. Internally we were trying to be Maven-esque since most internal Java-gone-Ruby developers at the client used Maven previously (and apparently loved it), but that is a very small number of real Ruby developers in the "wild":) > 4. What about dependencies that are required for more than one category? > 5. What would the new gem .gemspec file format look like? > Specifically, what about dependencies in more than one category? Do > you propose adding a new optional parameter to > Gem::Specification.add_dependency? If this accepted a string or an > array, it would handle the multiple-category issue. Great question and I should have mentioned this in the first post. Indeed the last argument accepted is an array (the usual Ruby way) and in our implementation, multiple dependencies were added under the surface when multiple categories were specified. >>>> s.add_dependency('rubygems', '>=0.8.0', :build, :test) which is equivalent to: >>>> s.add_dependency('rubygems', '>=0.8.0', :build) >>>> s.add_dependency('rubygems', '>=0.8.0', :test) However, there might be implications that I haven't thought of regarding adding this. Internally we haven't been bitten by anything that we couldn't fix ourselves, but I am always open to learning historical context that isn't obvious from the codebase or documentation that may affect the proposal. Thanks and will start looking at the RubyGems trunk and mature popular project gemspecs (for bw compat) over the weekend. Please feel free to continue the dialog if there are items that still need addressing. Susan -- mailto:me at susanpotter.net www:http://susanpotter.net blog:http://snakesgemscoffee.susanpotter.net linkedin:http://linkedin.com/in/susanpotter From Daniel.Berger at qwest.com Fri Feb 1 10:35:33 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Fri, 1 Feb 2008 09:35:33 -0600 Subject: [Rubygems-developers] WARNINGS In-Reply-To: References: <87AE92A5-A3E4-4531-8A2A-46B0588171EA@segment7.net> <809941D6-7A54-406B-A47C-9657E154B799@segment7.net> Message-ID: <7524A45A1A5B264FA4809E2156496CFB023D2F53@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: rubygems-developers-bounces at rubyforge.org > [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf Of Trans > Sent: Friday, February 01, 2008 6:45 AM > To: rubygems-developers at rubyforge.org > Subject: Re: [Rubygems-developers] WARNINGS > > > > On Feb 1, 5:22 am, Eric Hodel wrote: > > > So you get a warning. > > Is there a means for suppressing the warnings? If not could > you add one --check $VERBOSE, for instance? > > Actually, a way to suppress the entire output would be nice. > A number of people have created secondary tools for > generating gems (eg. > GemPackageTask), it would be nice to have control over the > output of that process. Mm, wouldn't it be nice to have structured warnings that you could disable altogether or temporarily within a block? Regards, Broken Record This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From Daniel.Berger at qwest.com Fri Feb 1 13:54:09 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Fri, 1 Feb 2008 12:54:09 -0600 Subject: [Rubygems-developers] warnings from open-uri In-Reply-To: References: Message-ID: <7524A45A1A5B264FA4809E2156496CFB023D2F5A@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: rubygems-developers-bounces at rubyforge.org > [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf > Of Chad Woolley > Sent: Friday, January 25, 2008 11:05 AM > To: rubygems-developers at rubyforge.org > Subject: [Rubygems-developers] warnings from open-uri > > Can I get some feedback on this: > > http://rubyforge.org/tracker/index.php?func=detail&aid=17042&g > roup_id=126&atid=575 > > It spews warnings constantly during our test and app > execution. I can take a shot at a patch, but I'm unsure > where to start. What is the issue, and what is the right way > to fix it? Namespace the rubygems version? How would that > work, and what would it break? Eric, it looks like we're bundling open-uri.rb in rubygems. May I ask why? Thanks, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From Daniel.Berger at qwest.com Fri Feb 1 14:04:01 2008 From: Daniel.Berger at qwest.com (Berger, Daniel) Date: Fri, 1 Feb 2008 13:04:01 -0600 Subject: [Rubygems-developers] warnings from open-uri In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB023D2F5A@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB023D2F5A@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <7524A45A1A5B264FA4809E2156496CFB023D2F5B@ITOMAE2KM01.AD.QINTRA.COM> > -----Original Message----- > From: rubygems-developers-bounces at rubyforge.org > [mailto:rubygems-developers-bounces at rubyforge.org] On Behalf > Of Berger, Daniel > Sent: Friday, February 01, 2008 11:54 AM > To: rubygems-developers at rubyforge.org > Subject: Re: [Rubygems-developers] warnings from open-uri > > > -----Original Message----- > > From: rubygems-developers-bounces at rubyforge.org > > [mailto:rubygems-developers-bounces at rubyforge.org] On > Behalf Of Chad > > Woolley > > Sent: Friday, January 25, 2008 11:05 AM > > To: rubygems-developers at rubyforge.org > > Subject: [Rubygems-developers] warnings from open-uri > > > > Can I get some feedback on this: > > > > http://rubyforge.org/tracker/index.php?func=detail&aid=17042&g > > roup_id=126&atid=575 > > > > It spews warnings constantly during our test and app > execution. I can > > take a shot at a patch, but I'm unsure where to start. What is the > > issue, and what is the right way to fix it? Namespace the rubygems > > version? How would that work, and what would it break? > > Eric, it looks like we're bundling open-uri.rb in rubygems. > May I ask why? Upon further review, it looks like we include the open-uri.rb from 1.9 because the 1.8.5 (1.8.x?) version does not support user/password on authenticating proxies. That's what Jim Weirich's comment says anyway. I can only guess that you are explicitly require'ing open-uri.rb at some point in your test suite Chad. Then, when you require rubygems, it loads the 1.9 version, and you end up with the warnings. I'm not sure what the solution is for you other than, "Don't do that". Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From thewoolleyman at gmail.com Fri Feb 1 18:48:46 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Fri, 1 Feb 2008 16:48:46 -0700 Subject: [Rubygems-developers] warnings from open-uri In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB023D2F5B@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB023D2F5A@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB023D2F5B@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: On Feb 1, 2008 12:04 PM, Berger, Daniel wrote: > Upon further review, it looks like we include the open-uri.rb from 1.9 > because the 1.8.5 (1.8.x?) version > does not support user/password on authenticating proxies. That's what > Jim Weirich's comment says anyway. > > I can only guess that you are explicitly require'ing open-uri.rb at some > point in your test suite Chad. Then, when you require rubygems, it loads > the 1.9 version, and you end up with the warnings. You mean I am requiring the old 1.8.5 open-uri first, rather than the 1.9 version from rubygems? I'll look into that. I'm not explicitly requiring open-uri, but I am requiring some files explicitly out of RubyGems, as part of GemInstaller (which programatically calls the RubyGems API). I guess I may be doing something in the wrong order. This points me in the right direction, though. Thanks. -- Chad > > I'm not sure what the solution is for you other than, "Don't do that". From thewoolleyman at gmail.com Fri Feb 1 20:26:56 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Fri, 1 Feb 2008 18:26:56 -0700 Subject: [Rubygems-developers] RubyGems Dependency Type In-Reply-To: <1076b0d90802010717r587b5901k43a539723590fa49@mail.gmail.com> References: <1076b0d90801301032hb5ba5d1qf93d5287172d3a21@mail.gmail.com> <1076b0d90802010717r587b5901k43a539723590fa49@mail.gmail.com> Message-ID: On Feb 1, 2008 8:17 AM, Susan Potter wrote: > Internally we were trying to be Maven-esque since most internal > Java-gone-Ruby developers at the client used Maven previously (and > apparently loved it), but that is a very small number of real Ruby > developers in the "wild":) Hehe. I'm one of that very small number - The dependency and version management philosophy of Maven is what inspired GemInstaller. Unfortunately, many Ruby developers, even very prominent ones, *underestimate* the "power of versions" ;) -- Chad From drbrain at segment7.net Sun Feb 3 19:27:02 2008 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 3 Feb 2008 16:27:02 -0800 Subject: [Rubygems-developers] WARNINGS In-Reply-To: References: <87AE92A5-A3E4-4531-8A2A-46B0588171EA@segment7.net> <809941D6-7A54-406B-A47C-9657E154B799@segment7.net> Message-ID: On Feb 1, 2008, at 05:45 AM, Trans wrote: > On Feb 1, 5:22 am, Eric Hodel wrote: > >> So you get a warning. > > Is there a means for suppressing the warnings? Not directly. > If not could you add one --check $VERBOSE, for instance? No. The warnings are a strong suggestion that something could be improved in your gem. I'd like to improve the quality of Ruby software everywhere, and hiding these warnings by default doesn't help us to do that. I really don't think it is onerous to fill in an author, email, homepage, rubyforge_project, summary, and to provide RDoc. I've worked on nearly forty gems, and it hasn't been difficult for me. > Actually, a way to suppress the entire output would be nice. A number > of people have created secondary tools for generating gems (eg. > GemPackageTask), it would be nice to have control over the output of > that process. You can control output of all of RubyGems (except for deprecations) via Gem::UserInteraction. From drbrain at segment7.net Sun Feb 3 19:28:29 2008 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 3 Feb 2008 16:28:29 -0800 Subject: [Rubygems-developers] WARNINGS In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB023D2F53@ITOMAE2KM01.AD.QINTRA.COM> References: <87AE92A5-A3E4-4531-8A2A-46B0588171EA@segment7.net> <809941D6-7A54-406B-A47C-9657E154B799@segment7.net> <7524A45A1A5B264FA4809E2156496CFB023D2F53@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <0290DD09-EE9A-4CA7-B233-6B6FB805E954@segment7.net> On Feb 1, 2008, at 07:35 AM, Berger, Daniel wrote: > Mm, wouldn't it be nice to have structured warnings that you could > disable altogether or temporarily within a block? From the API, this is possible. With the default tools it is not. From drbrain at segment7.net Sun Feb 3 19:40:14 2008 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 3 Feb 2008 16:40:14 -0800 Subject: [Rubygems-developers] RubyGems Dependency Type In-Reply-To: <1076b0d90801301032hb5ba5d1qf93d5287172d3a21@mail.gmail.com> References: <1076b0d90801301032hb5ba5d1qf93d5287172d3a21@mail.gmail.com> Message-ID: <6B23DC17-6988-4584-821E-3191B4842BF1@segment7.net> On Jan 30, 2008, at 10:32 AM, Susan Potter wrote: > The following is the scheme I used at my client (but with a few > client-specific things thrown in that I will not discuss here as they > aren't relevant for solving *this* particular problem): > > * each dependency when defined has a "type". I have personally used > the following types for Ruby to make more sense for our world: > runtime (default), compile (for Ruby/C extension purposes), test. > > * on "gem install" (unless otherwise told) the runtime dependencies > are installed only. I added a flag to the gem CLI (again through > extension). Of course, this again only works in our internal, fully > controlled system. > > Here is my proposal open to feedback since my background is primarily > in the server-side enterprise space (I am directly answering Eric > Hodel's questions from below): > > * should developer dependencies by installed by default? >>> No > * what does the command-line option look like? >>> gem install -Dall or gem install -Dtest or gem install -Dcompile >>> test installs runtime AND test dependencies. compile installs >>> runtime AND compile dependencies. all installs all three: runtime, >>> compile and test. > * what happens on uninstall? >>> ??? The client implementation I have currently only uninstalls the >>> given gem(s), but this needs further thinking as I realize this is >>> not >>> optimum. Mainly, this is in regards to `gem uninstall --ignore-dependencies`, which dependencies should be checked? Should we add the -D flags to uninstall, or stick with just checking runtime dependencies (I think the runtime-only is most beneficial). > * what should `gem check` do if all dependencies aren't installed? >>> in my proposed implementation I have found it useful to only check >>> runtime by default, but if -D is specified it will check those as >>> per >>> the CLI option noted above. `gem check` is supposed to run the tests, so should it may need to inform the user that the test dependencies are missing. > To be honest, I think the thing that matters most is that RubyGems > provides a way to describe this metadata and then we can worry about > tools and facilities to wrap around this later. If people do not want > to set the extra dependency type, that is fine, we default it to > runtime and Gem developers aren't any worse off than they are now. As in, all dependencies are runtime by default? Sounds good. > If you want to do extra things based on RAILS_ENV or MERB_ENV or > another environmental setting you can do so with something like > GemInstaller or another RubyGems "extension". In fact, I think simply > adding the metadata property of Gem::Dependency#type (ok, we use #kind > because of #type history) to RubyGems gives greater flexibility rather > than only providing one facility (e.g. GemInstaller, that you > essentially have to be married to). We can even defer how people > handle installing using these dependency types to third party Gems > instead of involving RubyGems in that business. As in, RubyGems provides only runtime, compile and test dependencies, but allows people to define other types? > I am willing and able (with about 3-5 hours a week to commit to open > source contributions across the board) to do most of the grunt work > and submit a patch for RubyGems project to do the capturing of the > metadata and change the gem CLI behavior depending on accepted > proposal. Unfortunately I cannot just open source the client work I > have already done since it is considered proprietary. I'd really like to see something like this added to RubyGems, provided I don't have to do all of the heavy lifting. If you have the time, please contribute it. From drbrain at segment7.net Sun Feb 3 19:40:24 2008 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 3 Feb 2008 16:40:24 -0800 Subject: [Rubygems-developers] RubyGems Dependency Type In-Reply-To: References: <1076b0d90801301032hb5ba5d1qf93d5287172d3a21@mail.gmail.com> Message-ID: <7B123B77-A024-4418-92C4-8FBDFBD66E0E@segment7.net> On Jan 30, 2008, at 13:16 PM, Chad Woolley wrote: > I know that Eric is in the camp of "install everything everywhere", > but the fact is that many people just are not comfortable with that. To be clear, I'm in that camp because nobody else has volunteered to make it work :) From alexey.verkhovsky at gmail.com Wed Feb 6 18:47:22 2008 From: alexey.verkhovsky at gmail.com (Alexey Verkhovsky) Date: Wed, 6 Feb 2008 23:47:22 +0000 Subject: [Rubygems-developers] "misnamed gem" error when building platform-specific gem repository on i386-linux platform Message-ID: <3945c4270802061547t6bda6916u36aabf9fd78a01e0@mail.gmail.com> Hello all, I'm upgrading RubyGems to 1.0.1 in RubyWorks repository (which, among other things, includes gems with precompiled extensions), and having the following problem: 1. In the process of installing the gem with extensions, we set spec.platform to Config::CONFIG['arch'], which is 'i386-linux' 2. Gem::Builder#build creates the new gem file, which uses @spec.file_name as a name. As it happens, @spec.file_name replaces the platform from i386-linux to x86-linux, so I end up with a file name like 'mongrel-1.1.3-x86-linux.gem' 3. In a later step, the build is indexing gem repository using 'gem generate_index' command. At this time, Gem::Indexer#build_index performs this check: gemfile =~ /\/#{Regexp.escape spec.original_name}.*\.gem\z/i Note that it uses spec.original_name, not spec.full_name. Of course, none of the *-x86-linux.gem files satisfy this check. Oops. So, is it a simple bug in the indexer.rb (which should use spec.full_name, not spec.original_name), or am I doing something wrong? -- Alexey Verkhovsky CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] RubyWorks [http://rubyworks.thoughtworks.com] From thewoolleyman at gmail.com Fri Feb 8 15:51:41 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Fri, 8 Feb 2008 13:51:41 -0700 Subject: [Rubygems-developers] warnings from open-uri In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB023D2F5B@ITOMAE2KM01.AD.QINTRA.COM> References: <7524A45A1A5B264FA4809E2156496CFB023D2F5A@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB023D2F5B@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: On Feb 1, 2008 12:04 PM, Berger, Daniel wrote: > Upon further review, it looks like we include the open-uri.rb from 1.9 > because the 1.8.5 (1.8.x?) version > does not support user/password on authenticating proxies. That's what > Jim Weirich's comment says anyway. > > I can only guess that you are explicitly require'ing open-uri.rb at some > point in your test suite Chad. Then, when you require rubygems, it loads > the 1.9 version, and you end up with the warnings. > > I'm not sure what the solution is for you other than, "Don't do that". I've attached a patch which avoids the double require and associated warnings. Please review here: http://rubyforge.org/tracker/index.php?func=detail&aid=17042&group_id=126&atid=575 Thanks, -- Chad From drbrain at segment7.net Sun Feb 10 18:10:10 2008 From: drbrain at segment7.net (Eric Hodel) Date: Sun, 10 Feb 2008 15:10:10 -0800 Subject: [Rubygems-developers] "misnamed gem" error when building platform-specific gem repository on i386-linux platform In-Reply-To: <3945c4270802061547t6bda6916u36aabf9fd78a01e0@mail.gmail.com> References: <3945c4270802061547t6bda6916u36aabf9fd78a01e0@mail.gmail.com> Message-ID: On Feb 6, 2008, at 15:47 PM, Alexey Verkhovsky wrote: > Hello all, > > I'm upgrading RubyGems to 1.0.1 in RubyWorks repository (which, among > other things, includes gems with precompiled extensions), and having > the following problem: > > 1. In the process of installing the gem with extensions, we set > spec.platform to Config::CONFIG['arch'], which is 'i386-linux' Use Ruby::Platform::CURRENT if your gem contains compiled files. > 2. Gem::Builder#build creates the new gem file, which uses > @spec.file_name as a name. As it happens, @spec.file_name replaces the > platform from i386-linux to x86-linux, so > I end up with a file name like 'mongrel-1.1.3-x86-linux.gem' > > 3. In a later step, the build is indexing gem repository using 'gem > generate_index' command. At this time, Gem::Indexer#build_index > performs this check: > gemfile =~ /\/#{Regexp.escape spec.original_name}.*\.gem\z/i > > Note that it uses spec.original_name, not spec.full_name. Of course, > none of the *-x86-linux.gem files satisfy this check. Oops. > > So, is it a simple bug in the indexer.rb (which should use > spec.full_name, not spec.original_name), No. This check is for legacy gems. > or am I doing something wrong? Follow the new API as described in the release notes (set it to Gem::Platform::CURRENT). irb(main):006:0> s = Gem::Specification.new irb(main):008:0> s.name = 'test' irb(main):009:0> s.version = 1 irb(main):010:0> s.platform = Gem::Platform::CURRENT irb(main):011:0> s.full_name => "test-1-x86-linux" irb(main):012:0> s.original_name => "test-1-x86-linux" From thewoolleyman at gmail.com Thu Feb 14 12:14:28 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Thu, 14 Feb 2008 10:14:28 -0700 Subject: [Rubygems-developers] warnings from open-uri In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB023D2F5A@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB023D2F5B@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: On Fri, Feb 8, 2008 at 1:51 PM, Chad Woolley wrote: > I've attached a patch which avoids the double require and associated > warnings. Please review here: > > > http://rubyforge.org/tracker/index.php?func=detail&aid=17042&group_id=126&atid=575 Could someone do a quick review of this and let me know if it is an acceptable workaround patch, or if something different is needed? Basically, it forces the rubygems-bundled openuri with the nonstandard path to always be used, by shoving the standard path of the ruby-core open uri onto the require array, thus avoiding the double-require. Thanks, -- Chad From transfire at gmail.com Sun Feb 17 15:17:06 2008 From: transfire at gmail.com (Trans) Date: Sun, 17 Feb 2008 12:17:06 -0800 (PST) Subject: [Rubygems-developers] Gem is installing ri docs in with core and standard's Message-ID: I've managed some clarity with ri today. I hadn't understood before now exactly where/how the shared ri docs were being stored. But now I see they are going into wither /usr/share/ri/1.8/system or /usr/share/ ri/1.8/site (your prefix and version may vary). Now that I know this, two issues become clear. The first is a general issue: how does ri prevent extension clobbering? For instance, if a lib overrides a Kernel method and the ri's are generated and stored in the system dir, how does it not just kill the original? If that's true I would think the ri docs should be separated by package names. Second (and this is why I post here) why is gems installing ri docs to the system directory? I was wondering why the ri --system flag did not help me see core/standard ruby only. Now I know. It seems to me gem's ri docs should have their own location along side system, and site, namely /usr/sahre/ri/1.8/gem. T. From drbrain at segment7.net Wed Feb 20 00:25:00 2008 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 19 Feb 2008 21:25:00 -0800 Subject: [Rubygems-developers] warnings from open-uri In-Reply-To: References: <7524A45A1A5B264FA4809E2156496CFB023D2F5A@ITOMAE2KM01.AD.QINTRA.COM> <7524A45A1A5B264FA4809E2156496CFB023D2F5B@ITOMAE2KM01.AD.QINTRA.COM> Message-ID: <3B1A9700-9089-4C45-A5CD-28DB14E30EF7@segment7.net> On Feb 14, 2008, at 09:14 AM, Chad Woolley wrote: > On Fri, Feb 8, 2008 at 1:51 PM, Chad Woolley > wrote: >> I've attached a patch which avoids the double require and associated >> warnings. Please review here: >> >> >> http://rubyforge.org/tracker/index.php?func=detail&aid=17042&group_id=126&atid=575 > > Could someone do a quick review of this and let me know if it is an > acceptable workaround patch, or if something different is needed? > Basically, it forces the rubygems-bundled openuri with the nonstandard > path to always be used, by shoving the standard path of the ruby-core > open uri onto the require array, thus avoiding the double-require. Aaron Patterson just finished a patch that replaces open-uri with plain 'ol Net::HTTP with keepalives, so we get the benefit of fast metadata updates no warnings from open-uri. From mikhailian at altern.org Wed Feb 20 05:44:24 2008 From: mikhailian at altern.org (Alexander Mikhailian) Date: Wed, 20 Feb 2008 10:44:24 +0000 (UTC) Subject: [Rubygems-developers] FAQ entry outdated Message-ID: The FAQ entry 2.4 Installing gems in a non-standard directory. [1] is outdated, again. The correct shell script is below, and the text should be edited, accordingly. PREFIX=$HOME export GEM_HOME=$PREFIX/lib/ruby/gems/1.8 export RUBYLIB=$PREFIX/lib ruby setup.rb all --prefix=$PREFIX [1] http://www.rubygems.org/read/chapter/15#page101 From drbrain at segment7.net Mon Feb 25 19:54:13 2008 From: drbrain at segment7.net (Eric Hodel) Date: Mon, 25 Feb 2008 16:54:13 -0800 Subject: [Rubygems-developers] RubyGems 1.1 Message-ID: <01F3D4CE-1C5C-43C7-B2E2-033757870DCE@segment7.net> Aaron Patterson checked in a replacement to OpenURI that uses persistent connections, which significantly speeds up metadata updates. Please test this out, especially if you are behind a proxy server. I'm going through the tracker, and have determined the following bugs should also be fixed for a 1.1 release. Any other nominations? `gem install` doesn't have proper exit code http://rubyforge.org/tracker/index.php?func=detail&aid=17438&group_id=126&atid=575 `gem update --system --version` always updates to latest http://rubyforge.org/tracker/index.php?func=detail&aid=16842&group_id=126&atid=575 rubygems 0.9.5 does not prefer local files over remote files when installing dependencies http://rubyforge.org/tracker/index.php?func=detail&aid=15759&group_id=126&atid=575 `gem update` re-installs the same version of a gem if there is a newer version for a different platform http://rubyforge.org/tracker/index.php?func=detail&aid=14780&group_id=126&atid=575 'gem update' does not properly install dependencies http://rubyforge.org/tracker/index.php?func=detail&aid=17488&group_id=126&atid=575 Rubygems 0.9.5 doesn't take care of already installed gems for local installation http://rubyforge.org/tracker/index.php?func=detail&aid=15790&group_id=126&atid=575 If these are easy, I will also look at: require_path order is unpredictable http://rubyforge.org/tracker/index.php?func=detail&aid=14533&group_id=126&atid=575 Gem::SourceIndex does not honor GEM_PATH ordering http://rubyforge.org/tracker/index.php?func=detail&aid=14816&group_id=126&atid=575 From thewoolleyman at gmail.com Tue Feb 26 13:27:03 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 26 Feb 2008 11:27:03 -0700 Subject: [Rubygems-developers] Best practices for managing GEM_PATH, GEM_HOME, and related stuff? Message-ID: I've been digging into the code in rubygems.rb and defaults.rb, and trying to understand how to manage GEM_PATH and/or GEM_HOME - specifically when invoking RubyGems programatically. I know some other people who are interested in this, so I'm going to throw out a few scenarios as discussion points. Scenario 1: Existing rubygems install, with some gems installed in the default system location. I want to programatically (such as Gem::GemRunner) install some additional gems in a user-writeable location (~/gems). After additional gems are installed, they should all (system and user-writable) be loadable with the 'gem' method and/or require. Scenario 2: Same as above, but on mac OS X Leopard, with all gems under default locations /System/Library/... and /Library/... still loadable That's it for now. What I'm looking for is a specific set of steps to accomplish the above scenarios. I don't need details on how to programatically install gems, I know that, but managing the env vars, default dir, and path is where I'm confused. I have some hacks to do this, but it involves manually setting up GEM_HOME and GEM_PATH before rubygems is ever required. This is hard in some environments - such as irb on Leopard, where rubygems is already required, and ENV['GEM_PATH'] is frozen. Maybe hard on others, such as ruby 1.9 with bundled rubygems? I haven't played with this under 1.9... Thanks, -- Chad From adam at heroku.com Tue Feb 26 18:58:16 2008 From: adam at heroku.com (Adam Wiggins) Date: Tue, 26 Feb 2008 15:58:16 -0800 Subject: [Rubygems-developers] Best practices for managing GEM_PATH, GEM_HOME, and related stuff? Message-ID: On 2/26/08, Chad Woolley wrote: > Scenario 1: Existing rubygems install, with some gems installed in the > default system location. I want to programatically (such as > Gem::GemRunner) install some additional gems in a user-writeable > location (~/gems). I'd love to be able to do this as well. If I'm not mistaken, this would be the gem installer reading from two different directories - GEM_HOME, the user-writeable directory, and GEM_PATH, the read-only system gems directory - and treating them as a single merged list when resolving dependencies. Adam From drbrain at segment7.net Tue Feb 26 20:07:33 2008 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 26 Feb 2008 17:07:33 -0800 Subject: [Rubygems-developers] Best practices for managing GEM_PATH, GEM_HOME, and related stuff? In-Reply-To: References: Message-ID: <12CFFB6E-4393-4ED6-AEA5-21524BC74DD0@segment7.net> On Feb 26, 2008, at 10:27 AM, Chad Woolley wrote: > Scenario 1: Existing rubygems install, with some gems installed in the > default system location. I want to programatically (such as > Gem::GemRunner) install some additional gems in a user-writeable > location (~/gems). After additional gems are installed, they should > all (system and user-writable) be loadable with the 'gem' method > and/or require. According to the documentation of your shell, set GEM_PATH to `gem env gempath` with ~/gems added set GEM_HOME to ~/gems At this point, `gem install` will install gems into ~/gems. > Scenario 2: Same as above, but on mac OS X Leopard, with all gems > under default locations /System/Library/... and /Library/... still > loadable Same. > That's it for now. What I'm looking for is a specific set of steps to > accomplish the above scenarios. I don't need details on how to > programatically install gems, I know that, but managing the env vars, > default dir, and path is where I'm confused. I should add a page to `gem help` for this. I'm switching `gem env gempath` to be usable by shell scripts for the next release, so you won't have to manually join them with ':'. > I have some hacks to do this, but it involves manually setting up > GEM_HOME and GEM_PATH before rubygems is ever required. This is > hard in some environments - such > as irb on Leopard, where rubygems is already required, and > ENV['GEM_PATH'] is frozen. Maybe hard on others, such as ruby 1.9 > with bundled rubygems? I haven't played with this under 1.9... Gem.clear_paths will force RubyGems to re-read GEM_HOME and GEM_PATH. From drbrain at segment7.net Tue Feb 26 20:37:41 2008 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 26 Feb 2008 17:37:41 -0800 Subject: [Rubygems-developers] Failing gem commands; reinstalling RubyGems In-Reply-To: <20080129101417.GA4184@linux.local> References: <20080122115746.GA4616@linux.local> <20080128132029.GB7971@linux.local> <20080128191255.GA3988@linux.local> <20080129101417.GA4184@linux.local> Message-ID: <879933E0-C302-47CA-A99A-86E136447155@segment7.net> On Jan 29, 2008, at 02:14 AM, Tobi Reif wrote: > On Mon 2008-01-28 Chad Woolley wrote: > [...] >>> I really would like to know what the recommended way is for >>> uninstalling / reinstalling RubyGems. Rich, Jim, Chad, Eric, what's >>> the "official" recommendation? >> >> Yes, I'd like to hear the latest and greatest official uninstall >> procedure as well... > > If there is no automated way, perhaps one could be added? Nobody has bothered to write it. From avatar at spellboundnet.com Tue Feb 26 21:24:24 2008 From: avatar at spellboundnet.com (Donavan Pantke) Date: Tue, 26 Feb 2008 21:24:24 -0500 Subject: [Rubygems-developers] Best practices for managing GEM_PATH, GEM_HOME, and related stuff? In-Reply-To: <12CFFB6E-4393-4ED6-AEA5-21524BC74DD0@segment7.net> References: <12CFFB6E-4393-4ED6-AEA5-21524BC74DD0@segment7.net> Message-ID: <200802262124.24780.avatar@spellboundnet.com> On Tuesday 26 February 2008 08:07:33 pm Eric Hodel wrote: > On Feb 26, 2008, at 10:27 AM, Chad Woolley wrote: > > Scenario 1: Existing rubygems install, with some gems installed in the > > default system location. I want to programatically (such as > > Gem::GemRunner) install some additional gems in a user-writeable > > location (~/gems). After additional gems are installed, they should > > all (system and user-writable) be loadable with the 'gem' method > > and/or require. > > According to the documentation of your shell, > > set GEM_PATH to `gem env gempath` with ~/gems added > set GEM_HOME to ~/gems > > At this point, `gem install` will install gems into ~/gems. Should we expose set_home and set_path? That way someone could override the current home and path according to what the caller wants. Thanks! Donavan From drbrain at segment7.net Tue Feb 26 22:00:46 2008 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 26 Feb 2008 19:00:46 -0800 Subject: [Rubygems-developers] Best practices for managing GEM_PATH, GEM_HOME, and related stuff? In-Reply-To: <200802262124.24780.avatar@spellboundnet.com> References: <12CFFB6E-4393-4ED6-AEA5-21524BC74DD0@segment7.net> <200802262124.24780.avatar@spellboundnet.com> Message-ID: <9D3E4A65-51E8-4A64-B625-77EAC1A1AD41@segment7.net> On Feb 26, 2008, at 18:24 PM, Donavan Pantke wrote: > On Tuesday 26 February 2008 08:07:33 pm Eric Hodel wrote: >> On Feb 26, 2008, at 10:27 AM, Chad Woolley wrote: >>> Scenario 1: Existing rubygems install, with some gems installed in >>> the >>> default system location. I want to programatically (such as >>> Gem::GemRunner) install some additional gems in a user-writeable >>> location (~/gems). After additional gems are installed, they should >>> all (system and user-writable) be loadable with the 'gem' method >>> and/or require. >> >> According to the documentation of your shell, >> >> set GEM_PATH to `gem env gempath` with ~/gems added >> set GEM_HOME to ~/gems >> >> At this point, `gem install` will install gems into ~/gems. > > Should we expose set_home and set_path? That way someone could > override the > current home and path according to what the caller wants. Probably, there needs to be some refactoring though, as Gem::path adds things to the path in case of APPLE_GEM_HOME. From thewoolleyman at gmail.com Tue Feb 26 22:33:12 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Tue, 26 Feb 2008 20:33:12 -0700 Subject: [Rubygems-developers] Best practices for managing GEM_PATH, GEM_HOME, and related stuff? In-Reply-To: <12CFFB6E-4393-4ED6-AEA5-21524BC74DD0@segment7.net> References: <12CFFB6E-4393-4ED6-AEA5-21524BC74DD0@segment7.net> Message-ID: On Tue, Feb 26, 2008 at 6:07 PM, Eric Hodel wrote: > set GEM_PATH to `gem env gempath` with ~/gems added > set GEM_HOME to ~/gems > > At this point, `gem install` will install gems into ~/gems. > > Gem.clear_paths will force RubyGems to re-read GEM_HOME and GEM_PATH. Thanks Eric! From transfire at gmail.com Wed Feb 27 08:28:03 2008 From: transfire at gmail.com (Trans) Date: Wed, 27 Feb 2008 05:28:03 -0800 (PST) Subject: [Rubygems-developers] Failing gem commands; reinstalling RubyGems In-Reply-To: <879933E0-C302-47CA-A99A-86E136447155@segment7.net> References: <20080122115746.GA4616@linux.local> <20080128132029.GB7971@linux.local> <20080128191255.GA3988@linux.local> <20080129101417.GA4184@linux.local> <879933E0-C302-47CA-A99A-86E136447155@segment7.net> Message-ID: <2a97aca9-f477-4e48-92a2-75348a30509b@8g2000hse.googlegroups.com> On Feb 26, 8:37 pm, Eric Hodel wrote: > On Jan 29, 2008, at 02:14 AM, Tobi Reif wrote: > > > On Mon 2008-01-28 Chad Woolley wrote: > > [...] > >>> I really would like to know what the recommended way is for > >>> uninstalling / reinstalling RubyGems. Rich, Jim, Chad, Eric, what's > >>> the "official" recommendation? > > >> Yes, I'd like to hear the latest and greatest official uninstall > >> procedure as well... > > > If there is no automated way, perhaps one could be added? > > Nobody has bothered to write it. I have. I've been trying to get a hold of Minero about the changes I made to setup.rb, but I haven't heard back. Probably not a good idea to push a setup.rb 3.5.0 w/o Minero's involvement. So if I don't hear back, I'm weighing options. Perhaps it would be better anyway to strip setup.rb down into a set of tasks that can be run either as standalone scripts or as rake tasks. I'm not sure, and I'm all ears for suggestions. T. From thewoolleyman at gmail.com Wed Feb 27 11:53:30 2008 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 27 Feb 2008 09:53:30 -0700 Subject: [Rubygems-developers] Failing gem commands; reinstalling RubyGems In-Reply-To: <2a97aca9-f477-4e48-92a2-75348a30509b@8g2000hse.googlegroups.com> References: <20080122115746.GA4616@linux.local> <20080128132029.GB7971@linux.local> <20080128191255.GA3988@linux.local> <20080129101417.GA4184@linux.local> <879933E0-C302-47CA-A99A-86E136447155@segment7.net> <2a97aca9-f477-4e48-92a2-75348a30509b@8g2000hse.googlegroups.com> Message-ID: On Wed, Feb 27, 2008 at 6:28 AM, Trans wrote: > Probably not a good idea to push a setup.rb 3.5.0 w/o Minero's > involvement. So if I don't hear back, I'm weighing options. Perhaps it > would be better anyway to strip setup.rb down into a set of tasks that > can be run either as standalone scripts or as rake tasks. I'm not > sure, and I'm all ears for suggestions. +1 for modular scripts - makes it easier to integrate programatically into other tools... From drbrain at segment7.net Wed Feb 27 14:59:25 2008 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 27 Feb 2008 11:59:25 -0800 Subject: [Rubygems-developers] Failing gem commands; reinstalling RubyGems In-Reply-To: <2a97aca9-f477-4e48-92a2-75348a30509b@8g2000hse.googlegroups.com> References: <20080122115746.GA4616@linux.local> <20080128132029.GB7971@linux.local> <20080128191255.GA3988@linux.local> <20080129101417.GA4184@linux.local> <879933E0-C302-47CA-A99A-86E136447155@segment7.net> <2a97aca9-f477-4e48-92a2-75348a30509b@8g2000hse.googlegroups.com> Message-ID: <75FF8390-0517-468E-BD8D-D3356D918E97@segment7.net> On Feb 27, 2008, at 05:28 AM, Trans wrote: > On Feb 26, 8:37 pm, Eric Hodel wrote: >> Nobody has bothered to write [a RubyGems uninstaller]. > > I have. I've been trying to get a hold of Minero about the changes I > made to setup.rb, but I haven't heard back. RubyGems doesn't use Minero's setup.rb any more. From transfire at gmail.com Wed Feb 27 22:02:27 2008 From: transfire at gmail.com (Trans) Date: Wed, 27 Feb 2008 19:02:27 -0800 (PST) Subject: [Rubygems-developers] Failing gem commands; reinstalling RubyGems In-Reply-To: <75FF8390-0517-468E-BD8D-D3356D918E97@segment7.net> References: <20080122115746.GA4616@linux.local> <20080128132029.GB7971@linux.local> <20080128191255.GA3988@linux.local> <20080129101417.GA4184@linux.local> <879933E0-C302-47CA-A99A-86E136447155@segment7.net> <2a97aca9-f477-4e48-92a2-75348a30509b@8g2000hse.googlegroups.com> <75FF8390-0517-468E-BD8D-D3356D918E97@segment7.net> Message-ID: <19ecde11-f4a0-47a7-89f9-e592c60b56c1@u69g2000hse.googlegroups.com> On Feb 27, 2:59 pm, Eric Hodel wrote: > On Feb 27, 2008, at 05:28 AM, Trans wrote: > > > On Feb 26, 8:37 pm, Eric Hodel wrote: > >> Nobody has bothered to write [a RubyGems uninstaller]. > > > I have. I've been trying to get a hold of Minero about the changes I > > made to setup.rb, but I haven't heard back. > > RubyGems doesn't use Minero's setup.rb any more. Ah, then you'll have to write an uninstaller yourself ;p T.