[Rubygems-developers] Ruby's --with-site-dir and Rubygems'
discordantus at gmail.com
Sat Apr 23 01:40:21 EDT 2005
[My reply went to Mark instead of the list. I'm redirecting his reply
to me here.]
On 4/22/05, Gavin Sinclair <gsinclair at soyabean.com.au> wrote:
> On Friday, April 22, 2005, 3:29:11 PM, Mark wrote:
> > Hi all,
> > Sorry in advance for my long-windedness. I've been working on this for
> > a long time, and I was unable to find a good solution on my own.
> > I'm working on a project that configures and compiles a customized
> > Ruby install. As part of this, the site_ruby directory is moved to a
> > separate location (using Ruby's --with-site-dir=path configure
> > option). This badly confuses the RubyGems setup, which then chooses a
> > strange place for it's gem_path.
> On the face of it, this shouldn't confuse RubyGems. All the
> information about site dir, etc., is available in the Config module
> (isn't it?), so RubyGems should have the info it needs to choose a
> directory for itself.
> Just let me ask: you _are_ following this procedure, aren't you?
> * Install Ruby (customised up the wazoo)
> * Use that Ruby to install RubyGems
> * Not stuff around with Ruby's or RubyGems' configuration afterwards
That's pretty much it. I do nothing with RubyGems that isn't in the setup.rb.
> If you're following that (broad) procedure and RubyGems is getting
> confused, I'd say RubyGems has a problem.
> Perhaps you could go into detail about all the directories involved.
> That would help confirm what RubyGems is doing.
Okay. *deep breath*
This customized Ruby install is actually a Ruby.framework, the native
format for installing libraries and their associated support files and
executables on OSX/*Step. This is the way Python is installed on OSX,
and it is hoped that we can get Ruby up to the same standard. For
RubyGems' purpose, the main difference is that the site_ruby directory
is part of an entirely different part of the directory tree from the
main install, not parallel to it.
Here are the main directories in this install.
The "framework" and "support" directories are OSX concepts, and Ruby
doesn't know or care about them (for now). But, in theory, an
administrator should be able to (fairly) safely add or remove items
from the support dir, and the framework dir should always be left
By default, Rubygems wanted to install most of it's files in the
framework directory, using Ruby's prefix. That would not be good, so I
specified a different prefix (for a sort of lightweight framework),
and a rubypath that would make sure ruby was found:
ruby setup.rb --prefix=/Library/Frameworks/RubyGems.framework/Versions/A \
I figured it would be okay for now to allow RubyGems to have free
reign over Ruby's support dir and the RubyGems framework dir. When I
installed, that's where all the files went. Except the sources gem,
which went in the gemdir; inside the Ruby.framework.
gems libs: /Library/Frameworks/Ruby.framework/Versions/1.8/lib/ruby/gems/1.8
The gem dir is inside the *main* ruby installation (in the framework),
not in the support dir, alongside the equivalent of the site_ruby
folder. While it technically works, this is a very bad setup, as bad
as if RubyGems were dumping files into ruby's stdlib directory. And I
don't think it's what was intended.
I realize why it would be hard to programmatically determine the
correct directory to choose for the gem dir. The way that is used
currently will work for nearly all installs, it just happens not to
for this one. I'm assuming that the gem directory was supposed to be
alongside the site_ruby directory, as they are the directories that
can be modified.
The easiest way (I think) to solve this would be to allow a setup
argument, so the path can be corrected if it appears wrong. Or, a bit
more in-depth analysis of the paths retrieved from Config::CONFIG
could be done. I'm trying to figure out how that might work...
Anyway, as I said, I'm very willing to help with this. Just tell me
what to do. The main reason I didn't just come up with a patch and
submit it is that there are probably going to be some decisions made
about the best way to handle this, and they aren't my decisions to
The ruby framework is currently in a pre-alpha state. Getting RubyGems
to *work* is, I feel, one of the requirements before moving to alpha
More information about the Rubygems-developers