From neil at brightbox.co.uk  Tue Jul  1 04:14:20 2008
From: neil at brightbox.co.uk (Neil Wilson)
Date: Tue, 1 Jul 2008 09:14:20 +0100
Subject: [Rubygems-developers] Customising Rubygems for Debian/Ubuntu.
In-Reply-To: <0CEB3E66-8971-4876-96D0-8AD321D6E2FD@segment7.net>
References: <50d9f33a0806252242o70d39d45x469be3a252d1d11a@mail.gmail.com>
	<BC7889B8-187D-4213-8C71-D90992573DBD@segment7.net>
	<50d9f33a0806270114s2ff4b263r11dfbc42e23b05fb@mail.gmail.com>
	<0CEB3E66-8971-4876-96D0-8AD321D6E2FD@segment7.net>
Message-ID: <50d9f33a0807010114i215ad9aub3962e6370f0daca@mail.gmail.com>

2008/6/30 Eric Hodel <drbrain at segment7.net>:
> Ok.
>
> In r1829 I have added:
>
> Gem.pre_install
> Gem.post_install
> Gem.pre_uninstall
> Gem.post_uninstall
>
> each takes a block that is saved then called with the
> Gem::Installer/Gem::Uninstaller instance for the gem being
> installed/uninstalled at the appropriate time.  Multiple pre/post install
> hooks are supported.
>
> Gem.post_install do |installer|
>  puts "!!! #{installer.spec.full_name} INSTALLED !!!"
> end
>
> Gem.post_uninstall do |uninstaller|
>  puts "!!! #{uninstaller.spec.full_name} UNINSTALLED !!!"
> end

Thanks for that Eric. I'll have a play.

Do I define these in the 'operating_system.rb' file, or elsewhere? And
I presume they act on all gems installed/uninstalled on a system (ie
the hook isn't specific to a gem and stored in the gem package
somewhere).


--
Neil Wilson

From drbrain at segment7.net  Tue Jul  1 16:12:14 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Tue, 1 Jul 2008 13:12:14 -0700
Subject: [Rubygems-developers] Customising Rubygems for Debian/Ubuntu.
In-Reply-To: <50d9f33a0807010114i215ad9aub3962e6370f0daca@mail.gmail.com>
References: <50d9f33a0806252242o70d39d45x469be3a252d1d11a@mail.gmail.com>
	<BC7889B8-187D-4213-8C71-D90992573DBD@segment7.net>
	<50d9f33a0806270114s2ff4b263r11dfbc42e23b05fb@mail.gmail.com>
	<0CEB3E66-8971-4876-96D0-8AD321D6E2FD@segment7.net>
	<50d9f33a0807010114i215ad9aub3962e6370f0daca@mail.gmail.com>
Message-ID: <6CED0E8A-32F9-402B-AFE9-1AAA2ED42A21@segment7.net>

On Jul 1, 2008, at 01:14 AM, Neil Wilson wrote:
> 2008/6/30 Eric Hodel <drbrain at segment7.net>:
>> Ok.
>>
>> In r1829 I have added:
>>
>> Gem.pre_install
>> Gem.post_install
>> Gem.pre_uninstall
>> Gem.post_uninstall
>
> Thanks for that Eric. I'll have a play.
>
> Do I define these in the 'operating_system.rb' file, or elsewhere? And
> I presume they act on all gems installed/uninstalled on a system (ie
> the hook isn't specific to a gem and stored in the gem package
> somewhere).

You would define what you need in operating_system.rb.

These hooks are only available for packagers and implementors, gems  
themselves cannot define any hooks.

One note I forgot to make was that they are called regardless of  
installation path, so if I run `gem install some_gem -i ~/tmp/gems`  
you may not want to update alternatives.  (Rubinius will take  
advantage of these to compile all the .rb files, for example).

Since I just remembered this, I added #bin_dir and #gem_home to  
Installer and Uninstaller so you can determine whether or not to run  
update alternatives.

From stephen.bannasch at deanbrook.org  Thu Jul  3 09:26:49 2008
From: stephen.bannasch at deanbrook.org (Stephen Bannasch)
Date: Thu, 3 Jul 2008 09:26:49 -0400
Subject: [Rubygems-developers] gem dependencies not working in rubygems
	1.2.0 on MacOS 10.5.3
Message-ID: <p06240804c492841694f6@[192.168.1.105]>

I've got rubygems 1.2.0 installed on MacOS 10.5.3 and when I tried to 
install sake it failed because I didn't have the proper ParseTree and 
ruby2ruby gems installed.

Bug report submitted:
http://rubyforge.org/tracker/index.php?func=detail&aid=21056&group_id=126&atid=575



From thewoolleyman at gmail.com  Thu Jul  3 15:13:15 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Thu, 3 Jul 2008 12:13:15 -0700
Subject: [Rubygems-developers] gem dependencies not working in rubygems
	1.2.0 on MacOS 10.5.3
In-Reply-To: <p06240804c492841694f6@192.168.1.105>
References: <p06240804c492841694f6@192.168.1.105>
Message-ID: <e3af97510807031213u106e08f0kf0a99324660cf80d@mail.gmail.com>

On Thu, Jul 3, 2008 at 6:26 AM, Stephen Bannasch
<stephen.bannasch at deanbrook.org> wrote:
> I've got rubygems 1.2.0 installed on MacOS 10.5.3 and when I tried to
> install sake it failed because I didn't have the proper ParseTree and
> ruby2ruby gems installed.
>
> Bug report submitted:
> http://rubyforge.org/tracker/index.php?func=detail&aid=21056&group_id=126&atid=575

Try running the same scenario, but with all commands (env, dependency)
run as sudo.  You are probably picking up a different env/rubygems
version in your root environment.  Not saying it is not a problem, but
we should see exactly what the env is for root to see why the sudo'd
installation is failing.

-- Chad

From stephen.bannasch at deanbrook.org  Thu Jul  3 16:47:40 2008
From: stephen.bannasch at deanbrook.org (Stephen Bannasch)
Date: Thu, 3 Jul 2008 16:47:40 -0400
Subject: [Rubygems-developers] gem dependencies not working in rubygems
 1.2.0 on MacOS 10.5.3
In-Reply-To: <e3af97510807031213u106e08f0kf0a99324660cf80d@mail.gmail.com>
References: <p06240804c492841694f6@192.168.1.105>
	<e3af97510807031213u106e08f0kf0a99324660cf80d@mail.gmail.com>
Message-ID: <p06240809c492e8707303@[192.168.1.105]>

At 12:13 PM -0700 7/3/08, Chad Woolley wrote:
>On Thu, Jul 3, 2008 at 6:26 AM, Stephen Bannasch
><stephen.bannasch at deanbrook.org> wrote:
>> I've got rubygems 1.2.0 installed on MacOS 10.5.3 and when I tried to
>> install sake it failed because I didn't have the proper ParseTree and
>> ruby2ruby gems installed.
>>
>> Bug report submitted:
> > http://rubyforge.org/tracker/index.php?func=detail&aid=21056&group_id=126&atid=575
>
>Try running the same scenario, but with all commands (env, dependency)
>run as sudo.  You are probably picking up a different env/rubygems
>version in your root environment.  Not saying it is not a problem, but
>we should see exactly what the env is for root to see why the sudo'd
>installation is failing.

Hi Chad, I updated the bug report with the tests you requested:

http://rubyforge.org/tracker/index.php?func=detail&aid=21056&group_id=126&atid=575

Still the same problem.

I also then tried installing gems into another ruby (ruby_1_8 head) that doesn't need sudo.

Same problem ... but a new realization.

uuidtools installed (no dependency)
rails installed (a number of dependencies)

sake didn't (dependencies listed, but not acted on)

Perhaps there is a way the dependencies are defined in sake (and perhaps other gems) that used to work and stopped working with 1.2.0.

From thewoolleyman at gmail.com  Fri Jul  4 01:02:23 2008
From: thewoolleyman at gmail.com (Chad Woolley)
Date: Thu, 3 Jul 2008 22:02:23 -0700
Subject: [Rubygems-developers] gem dependencies not working in rubygems
	1.2.0 on MacOS 10.5.3
In-Reply-To: <p06240809c492e8707303@192.168.1.105>
References: <p06240804c492841694f6@192.168.1.105>
	<e3af97510807031213u106e08f0kf0a99324660cf80d@mail.gmail.com>
	<p06240809c492e8707303@192.168.1.105>
Message-ID: <e3af97510807032202t4b4cd970qcad122830f78cdb@mail.gmail.com>

On Thu, Jul 3, 2008 at 1:47 PM, Stephen Bannasch
<stephen.bannasch at deanbrook.org> wrote:
> sake didn't (dependencies listed, but not acted on)
>
> Perhaps there is a way the dependencies are defined in sake (and perhaps other gems) that used to work and stopped working with 1.2.0.

Looks like a bug, I reproduced it.  Eric should take a look.  Here's
the debug output:

chadmac:~ woolley$ sudo gem install sake
ERROR:  Error installing sake:
	sake requires ParseTree (= 2.1.1, runtime)
chadmac:~ woolley$ sudo gem install sake --debug --verbose
Exception `NameError' at
/Library/Ruby/Site/1.8/rubygems/command_manager.rb:134 - uninitialized
constant Gem::Commands::InstallCommand
HEAD 200 OK: http://gems.rubyforge.org/latest_specs.4.8
Installing gem sake-1.0.15
Exception `IOError' at /Library/Ruby/Site/1.8/rubygems/format.rb:50 -
closed stream
Exception `Gem::InstallError' at
/Library/Ruby/Site/1.8/rubygems/installer.rb:175 - sake requires
ParseTree (= 2.1.1, runtime)
ERROR:  Error installing sake:
	sake requires ParseTree (= 2.1.1, runtime)

From luislavena at gmail.com  Fri Jul  4 02:26:00 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Fri, 4 Jul 2008 08:26:00 +0200
Subject: [Rubygems-developers] gem dependencies not working in rubygems
	1.2.0 on MacOS 10.5.3
In-Reply-To: <e3af97510807032202t4b4cd970qcad122830f78cdb@mail.gmail.com>
References: <p06240804c492841694f6@192.168.1.105>
	<e3af97510807031213u106e08f0kf0a99324660cf80d@mail.gmail.com>
	<p06240809c492e8707303@192.168.1.105>
	<e3af97510807032202t4b4cd970qcad122830f78cdb@mail.gmail.com>
Message-ID: <71166b3b0807032326i46c1c1f4oe1da3fedfa9d4944@mail.gmail.com>

On Fri, Jul 4, 2008 at 7:02 AM, Chad Woolley <thewoolleyman at gmail.com> wrote:
> On Thu, Jul 3, 2008 at 1:47 PM, Stephen Bannasch
> <stephen.bannasch at deanbrook.org> wrote:
>> sake didn't (dependencies listed, but not acted on)
>>
>> Perhaps there is a way the dependencies are defined in sake (and perhaps other gems) that used to work and stopped working with 1.2.0.
>
> Looks like a bug, I reproduced it.  Eric should take a look.  Here's
> the debug output:
>
> chadmac:~ woolley$ sudo gem install sake
> ERROR:  Error installing sake:
>        sake requires ParseTree (= 2.1.1, runtime)
> chadmac:~ woolley$ sudo gem install sake --debug --verbose
> Exception `NameError' at
> /Library/Ruby/Site/1.8/rubygems/command_manager.rb:134 - uninitialized
> constant Gem::Commands::InstallCommand
> HEAD 200 OK: http://gems.rubyforge.org/latest_specs.4.8
> Installing gem sake-1.0.15
> Exception `IOError' at /Library/Ruby/Site/1.8/rubygems/format.rb:50 -
> closed stream
> Exception `Gem::InstallError' at
> /Library/Ruby/Site/1.8/rubygems/installer.rb:175 - sake requires
> ParseTree (= 2.1.1, runtime)
> ERROR:  Error installing sake:
>        sake requires ParseTree (= 2.1.1, runtime)

I can confirm the same issue here.

If you manually install ParseTree:

gem install ParseTree --version '= 2.1.1'

It install properly...

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From luislavena at gmail.com  Sat Jul  5 11:03:33 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sat, 5 Jul 2008 17:03:33 +0200
Subject: [Rubygems-developers] Changes in setup.rb related to --destdir
Message-ID: <71166b3b0807050803k1c8aa9c3u5430728aee4af3fd@mail.gmail.com>

Hello everybody,

While working on RubyInstaller project, we found that version 1.2
included a --destdir option during the installation procedure
(setup.rb).

This new option, introduced several problems during setup for us, that
I and Eric fixed in the repository.

We found in RubyInstaller that using --prefix to install rubygems
outside ruby installation (for packaging process) was not clean
enough. destdir option was more appropriate.

The thing is destdir was not clever enough to detect paths with drive
letters, so we ended with a broken installation attempt.

To workaround this, Gordon Thiesfeld pointed me to the usage of
RbConfig::TOPDIR and leverage in Pathname to compute the path
relatives.

The following patch fixes the two install_destdir occurrences:

http://pastie.org/private/22dli3cc6lg0blmqzumda

Disregard the FIXME legend since do not apply, mainly because using
Pathname to compute the relative path we solve the drive letters :-)

Since the install_destdir code and functionality resides into
setup.rb, there is no testing mechanism for it.

Can the original author that proposed the destdir functionality review
this patch? I didn't had chance to test it on other platforms besides
Windows.

Thanks in advance and looking forward for the comments.
-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From vsizikov at gmail.com  Wed Jul  9 06:38:16 2008
From: vsizikov at gmail.com (Vladimir Sizikov)
Date: Wed, 9 Jul 2008 12:38:16 +0200
Subject: [Rubygems-developers] Customizing rubygems via #{RUBY_ENGINE}.rb
In-Reply-To: <8E05BEB7-FD7A-463F-A898-0713681C4419@segment7.net>
References: <3454c9680806251410q7f66fd3as3ad0567bec95c91d@mail.gmail.com>
	<02FB6BCF-B67A-4606-9209-F0427621F37E@segment7.net>
	<3454c9680806251453x1d38089cl20c8cc74f35072a5@mail.gmail.com>
	<8E05BEB7-FD7A-463F-A898-0713681C4419@segment7.net>
Message-ID: <3454c9680807090338o9e540f2qa8b146a193a7798e@mail.gmail.com>

Hi Eric,

Thanks for your support and responses, my comments below.

On Thu, Jun 26, 2008 at 1:50 AM, Eric Hodel <drbrain at segment7.net> wrote:
> Ok, I added Gem::ConfigFile::OPERATING_SYSTEM_DEFAULTS and
> PLATFORM_DEFAULTS.

And I just integrated that into JRuby.

> Add:
>
> Gem::ConfigFile::PLATFORM_DEFAULTS['install'] = '--env-shebang'
> Gem::ConfigFile::PLATFORM_DEFAULTS['update'] = '--env-shebang'
>
> I think this will work for `gem update`, but I'm not sure.  Can you let me
> know if it doesn't work?

Yes, this works perfectly in both cases (I had to add require
'rubygems/config_file' to JRuby's customization file jruby.rb though,
which seems to be the proper thing).

The only issue with this is that the help output that lists the
default options is not really updated accordingly. So, while we
endable --env-shebang in jruby.rb, users won't see from jruby -S gem
help install, that this option is enabled.

But, all in all, 4 more direct changes of official rubygems sources
are removed, and the only single one remains:

>>>> 2. installer.rb has shebang(bin_file_name) method that works not
>>>> ideally with JRuby on Windows,
>>>> and I'd like to provide customized version of that.

I'll talk about it in a separate email.

Thanks,
  --Vladimir

From joseluis.lucas at gmail.com  Mon Jul 14 04:20:29 2008
From: joseluis.lucas at gmail.com (jose luis lucas)
Date: Mon, 14 Jul 2008 10:20:29 +0200
Subject: [Rubygems-developers] Real networks statistics with GEMS
Message-ID: <ebede1f90807140120w3aa6acd9tc22721b0e393ada5@mail.gmail.com>

Hi, I'm new in GEMS community :)

Can I get statistics from ethernet/myrinet/infiniband networks (built in
simics simulator) using GEMS? I mean (4 example) latency, bandwidth, number
of paquets/flits sent/received, ...
Or only works with "interchips networks"?

Thanks in advance!
Lucas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rubygems-developers/attachments/20080714/670a8f96/attachment.html>

From hgs at dmu.ac.uk  Mon Jul 14 05:34:22 2008
From: hgs at dmu.ac.uk (Hugh Sasse)
Date: Mon, 14 Jul 2008 10:34:22 +0100 (BST)
Subject: [Rubygems-developers] Real networks statistics with GEMS
In-Reply-To: <ebede1f90807140120w3aa6acd9tc22721b0e393ada5@mail.gmail.com>
References: <ebede1f90807140120w3aa6acd9tc22721b0e393ada5@mail.gmail.com>
Message-ID: <alpine.LFD.1.10.0807141027100.10043@trueman.cs.cse.dmu.ac.uk>



On Mon, 14 Jul 2008, jose luis lucas wrote:

> Hi, I'm new in GEMS community :)
> 
> Can I get statistics from ethernet/myrinet/infiniband networks (built in
> simics simulator) using GEMS? I mean (4 example) latency, bandwidth,
> number of paquets/flits sent/received, ...
> Or only works with "interchips networks"?

You appear to be at cross purposes with this list.  Rubygems, or just gems,
almost never in ALLCAPS, is a packaging system for libraries for the Ruby
programming language.  There are some gems that support networking, but
your phrasing suggests that you think this is the main thrust of gems.

A quick prod of Google tells me, from a Cisco site, that:

The Gigabit Ethernet Module (GEM) provides Gigabit Ethernet
connectivity for a CSS 11800.

Maybe you want to be asking on a cisco list?  It's outside my expertise,
so I can't suggest which one.
> 
> Thanks in advance!
> Lucas
> 
>
         Hugh

From rubygems at freeze.org  Tue Jul 15 14:36:52 2008
From: rubygems at freeze.org (Jim Freeze)
Date: Tue, 15 Jul 2008 13:36:52 -0500
Subject: [Rubygems-developers] How to Setup Secure GemServer
Message-ID: <5cd596d60807151136p72fcb34ax7b0d4b4bf1241c94@mail.gmail.com>

Hi

Does anyone have some instructions on how to setup a secure gem server.
Basically, we want to be able to run our own gemserver behind https
and require some type of authentication.

I've never setup https, so don't know if this is trivial with gem server or not.

Thanks


-- 
Jim Freeze

From luislavena at gmail.com  Tue Jul 15 15:13:13 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Tue, 15 Jul 2008 21:13:13 +0200
Subject: [Rubygems-developers] How to Setup Secure GemServer
In-Reply-To: <5cd596d60807151136p72fcb34ax7b0d4b4bf1241c94@mail.gmail.com>
References: <5cd596d60807151136p72fcb34ax7b0d4b4bf1241c94@mail.gmail.com>
Message-ID: <71166b3b0807151213w5ddf5bcfie7f55fcb7a5763d5@mail.gmail.com>

On Tue, Jul 15, 2008 at 8:36 PM, Jim Freeze <rubygems at freeze.org> wrote:
> Hi
>
> Does anyone have some instructions on how to setup a secure gem server.
> Basically, we want to be able to run our own gemserver behind https
> and require some type of authentication.
>
> I've never setup https, so don't know if this is trivial with gem server or not.
>

Serving Gems is just like serving stating files, regarding
autorization I think you need to add that to the source url:

gem sources --add proto://user:password at host.domain.com/folder/

(don't forget the last slash after folder).

Is up to you generate the indexes ;-)

HTH,
-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From bwalton at artsci.utoronto.ca  Wed Jul 16 12:47:32 2008
From: bwalton at artsci.utoronto.ca (Ben Walton)
Date: Wed, 16 Jul 2008 12:47:32 -0400
Subject: [Rubygems-developers] exception during require 'somegem'
Message-ID: <1216226141-sup-7649@ntdws12.chass.utoronto.ca>

Hi List,

I'm in the process of setting up RoR on an old solaris 8 box and have
been building/installing ruby, etc by hand to get things going.  This
has led me to a problem with rubygems when gems are installed using an
overly strict umask.

If a user doesn't have rights to read the gem specification file, the
script 'requiring' the gem in question was bombing out with an unhandled 
exception in site_ruby/1.8/rubygems/source_index.rb (line 96).  Looking
at the code, it was due to spec_code being uninitialized (since the
exception was generated during the call to File.read(file_name) above.

The exception handler for this dumps the exception string concatenated
with the value of spec_code in a call to alert_warning.  This string
concatenation is the culprit that generates another exception when
spec_code is nil.

This isn't a proper patch, but I hope you'll use it (as at least a
reference) to correct the behaviour of the gem library in this case.

# diff source_index.rb*
96c96
<         alert_warning(e.inspect.to_s + "\n" + spec_code.to_s)
---
>         alert_warning(e.inspect.to_s + "\n" + spec_code)

My testing with this 'patch' applied shows that it does allow the
alert_warning method to proceed (whether it should or not is something
I'm not familiar enough with the inner workings of gems to answer)
causing things to die more normally later on during the require process.

Hope this helps.  Keep up the good work guys and girls!

Thanks
-Ben
-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/rubygems-developers/attachments/20080716/bb89abbe/attachment.bin>

From drbrain at segment7.net  Wed Jul 16 22:37:50 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Wed, 16 Jul 2008 19:37:50 -0700
Subject: [Rubygems-developers] How to Setup Secure GemServer
In-Reply-To: <5cd596d60807151136p72fcb34ax7b0d4b4bf1241c94@mail.gmail.com>
References: <5cd596d60807151136p72fcb34ax7b0d4b4bf1241c94@mail.gmail.com>
Message-ID: <A1849D6D-27B5-41C7-A35B-29F7F0038ACE@segment7.net>

On Jul 15, 2008, at 11:36 AM, Jim Freeze wrote:
> Does anyone have some instructions on how to setup a secure gem  
> server.
> Basically, we want to be able to run our own gemserver behind https
> and require some type of authentication.
>
> I've never setup https, so don't know if this is trivial with gem  
> server or not.

As of RubyGems 1.2.0, you should be able to fetch gems from an https  
repository, but I'm not sure.  I know earlier versions don't support  
fetching from https.

There are no provisions in RubyGems for authenticated gem repositories.

From drbrain at segment7.net  Wed Jul 16 22:41:02 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Wed, 16 Jul 2008 19:41:02 -0700
Subject: [Rubygems-developers] How to Setup Secure GemServer
In-Reply-To: <71166b3b0807151213w5ddf5bcfie7f55fcb7a5763d5@mail.gmail.com>
References: <5cd596d60807151136p72fcb34ax7b0d4b4bf1241c94@mail.gmail.com>
	<71166b3b0807151213w5ddf5bcfie7f55fcb7a5763d5@mail.gmail.com>
Message-ID: <6D8280C4-2713-4E1D-B961-CAA466DA94E3@segment7.net>

On Jul 15, 2008, at 12:13 PM, Luis Lavena wrote:
> On Tue, Jul 15, 2008 at 8:36 PM, Jim Freeze <rubygems at freeze.org>  
> wrote:
>> Does anyone have some instructions on how to setup a secure gem  
>> server.
>> Basically, we want to be able to run our own gemserver behind https
>> and require some type of authentication.
>>
>> I've never setup https, so don't know if this is trivial with gem  
>> server or not.
>
> Serving Gems is just like serving stating files, regarding
> autorization I think you need to add that to the source url:
>
> gem sources --add proto://user:password at host.domain.com/folder/

I heard a rumor that URI was going to stop supporting user:pass@ in  
1.9, but it seems to still work now.

> (don't forget the last slash after folder).

Fixed in 1.2 :)  In 1.1 I managed to refactor the rest of the code  
enough to make this easy to fix.

From cfis at savagexi.com  Sat Jul 19 16:18:29 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Sat, 19 Jul 2008 14:18:29 -0600
Subject: [Rubygems-developers] How to deal with binary dependencies?
Message-ID: <48824C15.4000804@savagexi.com>

I'd like to revisit a thread from last year:

http://rubyforge.org/pipermail/rubygems-developers/2007-March/002646.html

The problem is how to deal with binary dependencies within a GEM file. 
I think I've come up with a solution, and just posting here for anyone i 
the future that runs into the same problem.

To understand the issue, let's look at libxml-ruby.  For Windows, we 
include a compiled extension (libxml_ruby.so) in the lib directory.

In addition, we include a compiled libxml2-2.dll in the mingw directory 
since its highly likely that windows users don't have it.  Thus:

libxml-ruby
    ext
       <all the c code>
    lib
       libxml.rb
       libxml_ruby.so
    mingw
        MingW rake files
        libxml2-2.dll


When a user does require 'libxml' what happens:

1.  libxml.rb is loaded
2.  libxml.rb loads libxml_ruby.so
3.  libxml_ruby.so loads libxml2-2.dll

Its this third step that causes the issue.  Windows must be able to find 
libxml2-2.dll.  This is explained here:

http://msdn.microsoft.com/en-us/library/7d83bc18.aspx

Which basically means:

* The current directory (where the Ruby program is)
* In the Windows system directory or PATH
* In the root directory of the executable.  Since that's ruby.exe, that 
would be ruby/bin

Choices that do NOT work:

* libxml-ruby/lib
* site_ruby/1.8/i386-msvcrt
* Using the "app paths" registry key - that only seems to work for 
programs invoked from Windows Explorer via Shell Execute 
(http://msdn.microsoft.com/en-us/library/bb762153(VS.85).aspx)

The Ruby one-click installer goes with the third choice - its puts all 
its dlls in that directory (iconv.dll, libexpat.dll, readline.dll, 
gdbm.dll, etc.).

Phew, got all that?

So after playing around with this a  bit I see a few possible solutions:

*  Have GEMS support the need to move binary dependencies into the 
ruby/bin directory on Windows.  Same issue could happen on other OS's in 
theory, but you usually install libraries like libxml2 system wide. 
This is recommended practice by MSFT 
(http://msdn.microsoft.com/en-us/library/ms682600(VS.85).aspx - see last 
paragraph).

*  Have GEMS support the need to move binary dependencies into the 
site_ruby/1.8/i386-msvcrt directory and tell the user that they have to 
put that directory on the Windows path.  The problem with this of course 
is a) the extra user required step b) its opposite the precedent set by 
the one click install.

* Modify the PATH on the fly.  This can be done by setting ENV['path'] 
or SetDllDirectory 
(http://msdn.microsoft.com/en-us/library/ms686203(VS.85).aspx).  From 
testing, this solution in fact does work (I wasn't sure if it would).

Thoughts?  And more questions.  Should this be standardized?  Should 
there be a libs directory for dlls in gems?  Or should we reuse lib? 
Should there be an option to set the path for Windows?  Should there be 
the ability to check if the dll is already present (sort of like 
setup.rb does, but not using the C compiler, using LoadLibrary instead)

Thanks,

Charlie





















-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/rubygems-developers/attachments/20080719/eeeae935/attachment.bin>

From luislavena at gmail.com  Sun Jul 20 10:26:35 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Sun, 20 Jul 2008 16:26:35 +0200
Subject: [Rubygems-developers] How to Setup Secure GemServer
In-Reply-To: <6D8280C4-2713-4E1D-B961-CAA466DA94E3@segment7.net>
References: <5cd596d60807151136p72fcb34ax7b0d4b4bf1241c94@mail.gmail.com>
	<71166b3b0807151213w5ddf5bcfie7f55fcb7a5763d5@mail.gmail.com>
	<6D8280C4-2713-4E1D-B961-CAA466DA94E3@segment7.net>
Message-ID: <71166b3b0807200726o335df51bh34b904df21bf01c0@mail.gmail.com>

On Thu, Jul 17, 2008 at 4:41 AM, Eric Hodel <drbrain at segment7.net> wrote:
> On Jul 15, 2008, at 12:13 PM, Luis Lavena wrote:
>>
>> On Tue, Jul 15, 2008 at 8:36 PM, Jim Freeze <rubygems at freeze.org> wrote:
>>>
>>> Does anyone have some instructions on how to setup a secure gem server.
>>> Basically, we want to be able to run our own gemserver behind https
>>> and require some type of authentication.
>>>
>>> I've never setup https, so don't know if this is trivial with gem server
>>> or not.
>>
>> Serving Gems is just like serving stating files, regarding
>> autorization I think you need to add that to the source url:
>>
>> gem sources --add proto://user:password at host.domain.com/folder/
>
> I heard a rumor that URI was going to stop supporting user:pass@ in 1.9, but
> it seems to still work now.
>

Hmn, that will be bad, hope is jsut a rumor and nothing more.

>> (don't forget the last slash after folder).
>
> Fixed in 1.2 :)  In 1.1 I managed to refactor the rest of the code enough to
> make this easy to fix.

Great work Eric, the news will make a better world saving keystrokes
every day! ;-)

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From luislavena at gmail.com  Mon Jul 21 14:24:27 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 21 Jul 2008 20:24:27 +0200
Subject: [Rubygems-developers] How to deal with binary dependencies?
In-Reply-To: <48824C15.4000804@savagexi.com>
References: <48824C15.4000804@savagexi.com>
Message-ID: <71166b3b0807211124y4f3f0b0dpfde7314cc6e26a50@mail.gmail.com>

On Sat, Jul 19, 2008 at 10:18 PM, Charlie Savage <cfis at savagexi.com> wrote:
> I'd like to revisit a thread from last year:
>
> http://rubyforge.org/pipermail/rubygems-developers/2007-March/002646.html
>
> The problem is how to deal with binary dependencies within a GEM file. I
> think I've come up with a solution, and just posting here for anyone i the
> future that runs into the same problem.
>

Hey Charlie, I'll snip your message and focus on the issues... :-)

>
>
> When a user does require 'libxml' what happens:
>
> 1.  libxml.rb is loaded
> 2.  libxml.rb loads libxml_ruby.so
> 3.  libxml_ruby.so loads libxml2-2.dll
>
> Its this third step that causes the issue.  Windows must be able to find
> libxml2-2.dll.  This is explained here:
>
> http://msdn.microsoft.com/en-us/library/7d83bc18.aspx
>
> Which basically means:
>
> * The current directory (where the Ruby program is)
> * In the Windows system directory or PATH
> * In the root directory of the executable.  Since that's ruby.exe, that
> would be ruby/bin
>
> The Ruby one-click installer goes with the third choice - its puts all its
> dlls in that directory (iconv.dll, libexpat.dll, readline.dll, gdbm.dll,
> etc.).
>

Yes, that was to avoid user needing to add another folder to they
PATH, and one that is really long (like i386-msvcrt ...)

> Phew, got all that?
>
> So after playing around with this a  bit I see a few possible solutions:
>
> *  Have GEMS support the need to move binary dependencies into the ruby/bin
> directory on Windows.  Same issue could happen on other OS's in theory, but
> you usually install libraries like libxml2 system wide. This is recommended
> practice by MSFT
> (http://msdn.microsoft.com/en-us/library/ms682600(VS.85).aspx - see last
> paragraph).
>

Last paragraph states:

"It is good practice to install application DLLs in the same directory
that contains the application, even if you are not using DLL
redirection. This ensures that installing the application does not
overwrite other copies of the DLL and cause other applications to
fail. Also, if you follow this good practice, other applications do
not overwrite your copy of the DLL and cause your application to
fail."

So, that means is good to put the DLLs in ruby/bin, like One-Click
Installer is doing.

Before 0.9.5 and 1.0 release I tried to invest a bit on the method to
determine when a file is binary or not.

Right now RubyGems offer you a mechanism that set stubs in ruby/bin,
but that procedure doesn't like executables or even shared libraries
(dll):

http://rubyforge.org/pipermail/rubygems-developers/2007-October/003123.html

> *  Have GEMS support the need to move binary dependencies into the
> site_ruby/1.8/i386-msvcrt directory and tell the user that they have to put
> that directory on the Windows path.  The problem with this of course is a)
> the extra user required step b) its opposite the precedent set by the one
> click install.
>
> * Modify the PATH on the fly.  This can be done by setting ENV['path'] or
> SetDllDirectory
> (http://msdn.microsoft.com/en-us/library/ms686203(VS.85).aspx).  From
> testing, this solution in fact does work (I wasn't sure if it would).
>
> Thoughts?  And more questions.  Should this be standardized?  Should there
> be a libs directory for dlls in gems?  Or should we reuse lib? Should there
> be an option to set the path for Windows?  Should there be the ability to
> check if the dll is already present (sort of like setup.rb does, but not
> using the C compiler, using LoadLibrary instead)
>

Since we already have #executables and #bindir to define where those
are inside our gems.

What about #binaries? and we thread them different that executables
(verbatim copy them instead of adding shebangs).

Then we can have them inside our gem folder lib ('lib/libxml2-2.dll')
and be able to remove that when the gem involved get's also removed.

Thoughts?

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From cfis at savagexi.com  Mon Jul 21 14:57:29 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 21 Jul 2008 12:57:29 -0600
Subject: [Rubygems-developers] How to deal with binary dependencies?
In-Reply-To: <71166b3b0807211124y4f3f0b0dpfde7314cc6e26a50@mail.gmail.com>
References: <48824C15.4000804@savagexi.com>
	<71166b3b0807211124y4f3f0b0dpfde7314cc6e26a50@mail.gmail.com>
Message-ID: <4884DC19.9060600@savagexi.com>

> So, that means is good to put the DLLs in ruby/bin, like One-Click
> Installer is doing.

Yes, I think that is the right choice for the one click installer.

For an individual GEM, I think either solution is ok - a) copying the 
shared library to ruby/bin or b) manipulating the path to add the path 
the shared library

> Right now RubyGems offer you a mechanism that set stubs in ruby/bin,
> but that procedure doesn't like executables or even shared libraries
> (dll):
> 
> http://rubyforge.org/pipermail/rubygems-developers/2007-October/003123.html
> 
> Since we already have #executables and #bindir to define where those
> are inside our gems.
> 
> What about #binaries? and we thread them different that executables
> (verbatim copy them instead of adding shebangs).

I'd probably be more specific and define a new spec setting called 
"libraries" that means RubyGems will:

a) On installation copy the files marked "libraries" to ruby/bin
b) On loading a gem, update the path to include the location of the 
library files (if any are set).

So:

Directory:

libxml_ruby
   lib
     libxml2-2.dll


GemSpec:

spec.libraries << "lib/libxml2-2.dll"

How does that sound?

And what should I do in the short term?

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/rubygems-developers/attachments/20080721/4f3478ad/attachment.bin>

From luislavena at gmail.com  Mon Jul 21 15:15:02 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 21 Jul 2008 21:15:02 +0200
Subject: [Rubygems-developers] How to deal with binary dependencies?
In-Reply-To: <4884DC19.9060600@savagexi.com>
References: <48824C15.4000804@savagexi.com>
	<71166b3b0807211124y4f3f0b0dpfde7314cc6e26a50@mail.gmail.com>
	<4884DC19.9060600@savagexi.com>
Message-ID: <71166b3b0807211215x646c9ba9j435e2d57e505b76d@mail.gmail.com>

On Mon, Jul 21, 2008 at 8:57 PM, Charlie Savage <cfis at savagexi.com> wrote:
>> So, that means is good to put the DLLs in ruby/bin, like One-Click
>> Installer is doing.
>
> Yes, I think that is the right choice for the one click installer.
>
> For an individual GEM, I think either solution is ok - a) copying the shared
> library to ruby/bin or b) manipulating the path to add the path the shared
> library
>

Hmn, I was talking that One-Click Installer did that in the past since
it bundled a lot of extensions and gems, but we are shifting to a
gem-based design where RubyGems plan a important role.

Manipulating the path? that means change code in RubyGems to take care
of each gem that expose a "binary library"... I don't like the idea.

>> Right now RubyGems offer you a mechanism that set stubs in ruby/bin,
>> but that procedure doesn't like executables or even shared libraries
>> (dll):
>>
>>
>> http://rubyforge.org/pipermail/rubygems-developers/2007-October/003123.html
>>
>> Since we already have #executables and #bindir to define where those
>> are inside our gems.
>>
>> What about #binaries? and we thread them different that executables
>> (verbatim copy them instead of adding shebangs).
>
> I'd probably be more specific and define a new spec setting called
> "libraries" that means RubyGems will:
>

But a library is also a ruby library, which doesn't apply. Is it a
binary dependency of the extension bundled in the gem.

> a) On installation copy the files marked "libraries" to ruby/bin
> b) On loading a gem, update the path to include the location of the library
> files (if any are set).
>
> So:
>
> Directory:
>
> libxml_ruby
>  lib
>    libxml2-2.dll
>
>
> GemSpec:
>
> spec.libraries << "lib/libxml2-2.dll"
>
> How does that sound?
>

Hmn, that definetely add some platform specific code beyond what
RubyGems should be doing... and from POV I don't like it so much.

> And what should I do in the short term?
>

Indicate your users to copy the dll or provide a RubyGems binary
(minimal script) that performs the dll copy form that particular
folder into ruby/bin (Gem.bindir)

Something similar is what I do for mongrel_service.

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From cfis at savagexi.com  Mon Jul 21 15:23:15 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 21 Jul 2008 13:23:15 -0600
Subject: [Rubygems-developers] How to deal with binary dependencies?
In-Reply-To: <71166b3b0807211215x646c9ba9j435e2d57e505b76d@mail.gmail.com>
References: <48824C15.4000804@savagexi.com>	<71166b3b0807211124y4f3f0b0dpfde7314cc6e26a50@mail.gmail.com>	<4884DC19.9060600@savagexi.com>
	<71166b3b0807211215x646c9ba9j435e2d57e505b76d@mail.gmail.com>
Message-ID: <4884E223.6000107@savagexi.com>



Luis Lavena wrote:
> Hmn, I was talking that One-Click Installer did that in the past since
> it bundled a lot of extensions and gems, but we are shifting to a
> gem-based design where RubyGems plan a important role.
> 
> Manipulating the path? that means change code in RubyGems to take care
> of each gem that expose a "binary library"... I don't like the idea.

It has two big advantages.  First, you don't have to copy all libraries 
to one directory.  Second it solves the issue if 2 gems use different 
versions of the same dll (in the copying solution one gem will lose 
since its dll will be overwritten).

Remember, this path manipulation is only for the currently running 
process (not system wide) and is fully supported by the Windows api. 
Don't know about other OSes though, haven't looked.

>>> What about #binaries? and we thread them different that executables
>>> (verbatim copy them instead of adding shebangs).
>> I'd probably be more specific and define a new spec setting called
>> "libraries" that means RubyGems will:
>>
> 
> But a library is also a ruby library, which doesn't apply. Is it a
> binary dependency of the extension bundled in the gem.

Yes.  But there is a difference between a binary executable and a binary 
library.  I think we would regret calling them the same thing, because 
they are not.

>> a) On installation copy the files marked "libraries" to ruby/bin
>> b) On loading a gem, update the path to include the location of the library
>> files (if any are set).
>>
>> So:
>>
>> Directory:
>>
>> libxml_ruby
>>  lib
>>    libxml2-2.dll
>>
>>
>> GemSpec:
>>
>> spec.libraries << "lib/libxml2-2.dll"
>>
>> How does that sound?
>>
> 
> Hmn, that definetely add some platform specific code beyond what
> RubyGems should be doing... and from POV I don't like it so much.

Why is that platform specific code?  Any file listed in libraries gets 
copied to ruby/bin.

Of course, you might not want that to happen on all platforms, but to 
solve that you just provide platform specific gems (which obviously you 
have to anyway if the GEM include binary files).  For a Windows GEM 
you'd include the spec.libraries line, for other platform GEMS you would 
not.


>> And what should I do in the short term?
>>
> 
> Indicate your users to copy the dll or provide a RubyGems binary
> (minimal script) that performs the dll copy form that particular
> folder into ruby/bin (Gem.bindir)

Right - which is what we do now in the documentation.  I think that's a 
bad solution and want to avoid it.

> 
> Something similar is what I do for mongrel_service.
> 

Services are a bit different, in that you need admin rights to install.

Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/rubygems-developers/attachments/20080721/01e6b89f/attachment.bin>

From luislavena at gmail.com  Mon Jul 21 15:56:30 2008
From: luislavena at gmail.com (Luis Lavena)
Date: Mon, 21 Jul 2008 21:56:30 +0200
Subject: [Rubygems-developers] How to deal with binary dependencies?
In-Reply-To: <4884E223.6000107@savagexi.com>
References: <48824C15.4000804@savagexi.com>
	<71166b3b0807211124y4f3f0b0dpfde7314cc6e26a50@mail.gmail.com>
	<4884DC19.9060600@savagexi.com>
	<71166b3b0807211215x646c9ba9j435e2d57e505b76d@mail.gmail.com>
	<4884E223.6000107@savagexi.com>
Message-ID: <71166b3b0807211256lee8aa11ide0b60bc1787e917@mail.gmail.com>

On Mon, Jul 21, 2008 at 9:23 PM, Charlie Savage <cfis at savagexi.com> wrote:
>
>
> Luis Lavena wrote:
>>
>> Hmn, I was talking that One-Click Installer did that in the past since
>> it bundled a lot of extensions and gems, but we are shifting to a
>> gem-based design where RubyGems plan a important role.
>>
>> Manipulating the path? that means change code in RubyGems to take care
>> of each gem that expose a "binary library"... I don't like the idea.
>
> It has two big advantages.  First, you don't have to copy all libraries to
> one directory.  Second it solves the issue if 2 gems use different versions
> of the same dll (in the copying solution one gem will lose since its dll
> will be overwritten).
>

Yes, but also exposes issues and clashes if some gem bundles a dll
like OpenSSL which proven to clash with the openssl bindings. There is
a example of that scenario when running postgresql adapters, the
bundled openssl dll and trying to require 'openssl' library.

I saw that Ruby C openssl built/linked to a older version of openssl
(the one in ruby/bin) produce some errors when postgresql bundled dlls
precede in the PATH.

> Remember, this path manipulation is only for the currently running process
> (not system wide) and is fully supported by the Windows api. Don't know
> about other OSes though, haven't looked.
>

That means make RubyGems Ruby/DL dependant and include the
SetDllDirectory API. I'm not against that, but we need to know how
deep those modifications go.

>>>> What about #binaries? and we thread them different that executables
>>>> (verbatim copy them instead of adding shebangs).
>>>
>>> I'd probably be more specific and define a new spec setting called
>>> "libraries" that means RubyGems will:
>>>
>>
>> But a library is also a ruby library, which doesn't apply. Is it a
>> binary dependency of the extension bundled in the gem.
>
> Yes.  But there is a difference between a binary executable and a binary
> library.  I think we would regret calling them the same thing, because they
> are not.
>

Is better we find sooner a name to make them fit properly sooner than later :-)

>>> a) On installation copy the files marked "libraries" to ruby/bin
>>> b) On loading a gem, update the path to include the location of the
>>> library
>>> files (if any are set).
>>>
>>> So:
>>>
>>> Directory:
>>>
>>> libxml_ruby
>>>  lib
>>>   libxml2-2.dll
>>>
>>>
>>> GemSpec:
>>>
>>> spec.libraries << "lib/libxml2-2.dll"
>>>
>>> How does that sound?
>>>
>>
>> Hmn, that definetely add some platform specific code beyond what
>> RubyGems should be doing... and from POV I don't like it so much.
>
> Why is that platform specific code?  Any file listed in libraries gets
> copied to ruby/bin.
>

SetDllDirectory ? or you're talking about ENV['PATH'] alteration in this case?

> Of course, you might not want that to happen on all platforms, but to solve
> that you just provide platform specific gems (which obviously you have to
> anyway if the GEM include binary files).  For a Windows GEM you'd include
> the spec.libraries line, for other platform GEMS you would not.
>

I'll love to heard back from Eric and other RubyGems developers about this.

>
>>> And what should I do in the short term?
>>>
>>
>> Indicate your users to copy the dll or provide a RubyGems binary
>> (minimal script) that performs the dll copy form that particular
>> folder into ruby/bin (Gem.bindir)
>
> Right - which is what we do now in the documentation.  I think that's a bad
> solution and want to avoid it.
>

We agree :-P

>>
>> Something similar is what I do for mongrel_service.
>>
>
> Services are a bit different, in that you need admin rights to install.
>

Oh, I was not talking about installing services, I was talking about
mongrel_service use a small script to copy mongrel_service executable
into ruby/bin directory.

(I need to improve my english)

Regards,
-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

From cfis at savagexi.com  Mon Jul 21 16:16:19 2008
From: cfis at savagexi.com (Charlie Savage)
Date: Mon, 21 Jul 2008 14:16:19 -0600
Subject: [Rubygems-developers] How to deal with binary dependencies?
In-Reply-To: <71166b3b0807211256lee8aa11ide0b60bc1787e917@mail.gmail.com>
References: <48824C15.4000804@savagexi.com>	<71166b3b0807211124y4f3f0b0dpfde7314cc6e26a50@mail.gmail.com>	<4884DC19.9060600@savagexi.com>	<71166b3b0807211215x646c9ba9j435e2d57e505b76d@mail.gmail.com>	<4884E223.6000107@savagexi.com>
	<71166b3b0807211256lee8aa11ide0b60bc1787e917@mail.gmail.com>
Message-ID: <4884EE93.4090708@savagexi.com>

> Yes, but also exposes issues and clashes if some gem bundles a dll
> like OpenSSL which proven to clash with the openssl bindings. There is
> a example of that scenario when running postgresql adapters, the
> bundled openssl dll and trying to require 'openssl' library.

> I saw that Ruby C openssl built/linked to a older version of openssl
> (the one in ruby/bin) produce some errors when postgresql bundled dlls
> precede in the PATH.

If the dlls have the same name, but are different versions, and both are 
used in the same process, then yes you'd have an issue for that process. 
  But in the copying solution you have an even worse problem - you would 
have permanently broken one of the GEMS forever by overwriting its dll. 
  So I still see the copying solution is higher risk.  I agree there is 
no great solution here though.

Here is another example.  Libxml2.dll requires libiconv.  Ruby already 
has one, but libxml is using a newer one.  Different files name for now 
though, so no conflict.  But I'd hate to intall libxml and have it 
overwrite Ruby's iconv by mistake.

> 
>> Remember, this path manipulation is only for the currently running process
>> (not system wide) and is fully supported by the Windows api. Don't know
>> about other OSes though, haven't looked.
>>

> That means make RubyGems Ruby/DL dependant and include the
> SetDllDirectory API. I'm not against that, but we need to know how
> deep those modifications go.

Actually this works (at least on Windows):

ENV['PATH'] += 'path to library'

So actually you don't need the dependency on SetDllDirectory. But yes, 
point taken.  If you need to use SetDllDirectory, there would be a gem 
dependency on Win32API.

> 
>>>>> What about #binaries? and we thread them different that executables
>>>>> (verbatim copy them instead of adding shebangs).
>>>> I'd probably be more specific and define a new spec setting called
>>>> "libraries" that means RubyGems will:
>>>>
>>> But a library is also a ruby library, which doesn't apply. Is it a
>>> binary dependency of the extension bundled in the gem.
>> Yes.  But there is a difference between a binary executable and a binary
>> library.  I think we would regret calling them the same thing, because they
>> are not.
>>
> 
> Is better we find sooner a name to make them fit properly sooner than later :-)

Yes :)

I'd have 2 things, executables and libraries.  But if we decide to 
combine them, then your suggestion of binaries is good.

>>>>
>>>> GemSpec:
>>>>
>>>> spec.libraries << "lib/libxml2-2.dll"
>>>>
>>>> How does that sound?
>>>>
>>> Hmn, that definetely add some platform specific code beyond what
>>> RubyGems should be doing... and from POV I don't like it so much.
>> Why is that platform specific code?  Any file listed in libraries gets
>> copied to ruby/bin.
>>
> 
> SetDllDirectory ? or you're talking about ENV['PATH'] alteration in this case?

Oh, sorry.  I was thinking of the case that files added to spec.libaries 
are copied to ruby/bin.  Or if we did the PATH thing, then ENV['PATH']

But that raises a good point.  Whether we copy the files or manipulate 
the path, from a GEM developer point of view they will still be 
specified in the same way (spec.libraries, spec.binaries, 
spec.exetuables, or whatever we call them).  Note that here is an 
example of why having spec.executable and spec.libraries is better than 
just spec.binaries.  In the first case, you have to copy executables to 
ruby/bin but in the second you do not.

>> Of course, you might not want that to happen on all platforms, but to solve
>> that you just provide platform specific gems (which obviously you have to
>> anyway if the GEM include binary files).  For a Windows GEM you'd include
>> the spec.libraries line, for other platform GEMS you would not.
>>
> 
> I'll love to heard back from Eric and other RubyGems developers about this.

Definitely.

>>> Indicate your users to copy the dll or provide a RubyGems binary
>>> (minimal script) that performs the dll copy form that particular
>>> folder into ruby/bin (Gem.bindir)
>> Right - which is what we do now in the documentation.  I think that's a bad
>> solution and want to avoid it.
>>
> 
> We agree :-P
> 
>>> Something similar is what I do for mongrel_service.
>>>
>> Services are a bit different, in that you need admin rights to install.
>>
> 
> Oh, I was not talking about installing services, I was talking about
> mongrel_service use a small script to copy mongrel_service executable
> into ruby/bin directory.

Ah, I see.

> (I need to improve my english)

Your English seems great to me :)

Thanks for all your ideas and feedback, it really helps.

Charlie

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://rubyforge.org/pipermail/rubygems-developers/attachments/20080721/1083a6e7/attachment.bin>

From chris.zhu at sun.com  Tue Jul 22 03:48:44 2008
From: chris.zhu at sun.com (Chris Zhu)
Date: Tue, 22 Jul 2008 15:48:44 +0800
Subject: [Rubygems-developers] Put back of gem man page from Open Solaris.
Message-ID: <488590DC.90206@sun.com>

An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rubygems-developers/attachments/20080722/aaaba4ee/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gem.1
URL: <http://rubyforge.org/pipermail/rubygems-developers/attachments/20080722/aaaba4ee/attachment-0001.pl>

From jftucker at gmail.com  Wed Jul 23 06:17:40 2008
From: jftucker at gmail.com (James Tucker)
Date: Wed, 23 Jul 2008 11:17:40 +0100
Subject: [Rubygems-developers] gem file lists
Message-ID: <77ADEF99-F5DD-454A-B9E0-8439547689CB@gmail.com>

Quite some time ago I wrote a blog post about the number of temporary  
strings that are loaded when rubygems starts up. (The largest culprit  
is the file list for the gems).

I've been trying to think how to overcome this for some time, without  
breaking the gems api, but a slightly more lightweight idea came to me  
today, which may be workable prior to an architecture change.

Add another field for 'non-runtime files', for covering docs,  
examples, rakefiles, tests, etc.

This would enable gem authors to maintain the ability to scan the  
gemspec for important files (often under lib/), but unimportant files  
would be missed out.

Initial saving on a development machine (averaging what we use in the  
office), would seem to be around 30-40% of the instanced objects in a  
`ruby -rubygems -e ""`

On a related note, I was considering a more architectural changeset to  
gems, which I was going to stab case in a more external 'mini-gems'  
package (may be quite some time away).

The plan is to move to something that's glob supported (and a new  
directory structure aside that).

In order to accomplish this but maintain compatibility I envisage a  
Gem.source_index that binds data as late as possible. A useful api  
however would be to Gem.source_files.glob(), which would both simplify  
and abstract the necessary piece of work for many of the current  
'plugin' architectures built on top of Gem.source_index discovery. The  
hope being that this slowly opens up the floor to such architectural  
modifications, hiding them behind an API.

Any / all input would be most welcome,

Kind regards,

James.

From drbrain at segment7.net  Wed Jul 23 20:51:38 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Wed, 23 Jul 2008 17:51:38 -0700
Subject: [Rubygems-developers] gem file lists
In-Reply-To: <77ADEF99-F5DD-454A-B9E0-8439547689CB@gmail.com>
References: <77ADEF99-F5DD-454A-B9E0-8439547689CB@gmail.com>
Message-ID: <73097EE9-C5C9-4B02-9E6F-59C63457D99C@segment7.net>

On Jul 23, 2008, at 03:17 AM, James Tucker wrote:
> Quite some time ago I wrote a blog post about the number of  
> temporary strings that are loaded when rubygems starts up. (The  
> largest culprit is the file list for the gems).
>
> I've been trying to think how to overcome this for some time,  
> without breaking the gems api, but a slightly more lightweight idea  
> came to me today, which may be workable prior to an architecture  
> change.
>
> Add another field for 'non-runtime files', for covering docs,  
> examples, rakefiles, tests, etc.
>
> This would enable gem authors to maintain the ability to scan the  
> gemspec for important files (often under lib/), but unimportant  
> files would be missed out.
>
> Initial saving on a development machine (averaging what we use in  
> the office), would seem to be around 30-40% of the instanced objects  
> in a `ruby -rubygems -e ""`
>
> On a related note, I was considering a more architectural changeset  
> to gems, which I was going to stab case in a more external 'mini- 
> gems' package (may be quite some time away).

I discussed using gem_prelude.rb with Yehuda Katz, and I think  
something like a 'rubygems-small.rb' would work:

module Gem; end
require 'gem_prelude'

This uses the gem_prelude.rb that gets compiled into ruby 1.9, and I  
think is workable in 1.8 as well.  I've not made any experiments with  
it, though.

From whitethunder922 at yahoo.com  Mon Jul 28 17:00:42 2008
From: whitethunder922 at yahoo.com (Matt White)
Date: Mon, 28 Jul 2008 14:00:42 -0700 (PDT)
Subject: [Rubygems-developers] Rubygems Errors
Message-ID: <980325.89173.qm@web53304.mail.re2.yahoo.com>

I recently upgraded a server's rubygems from 0.9.0 to 1.2.0. Upon
doing so, one of our apps that uses soap4r thinks all the security
certificates it sees are invalid (see Error 1 below). I tried
reverting to 0.9.0, but anything that uses rubygems crashes now (see
Error 2 below). If anyone could help me solve either problem, that
would be great. Ideally, I'd like to run the latest version because
some of my new Rails apps have issues with the older version of
Rubygems. Thanks! 


=============Error 1=================
Processing MainController#index (for 76.2.163.148 at 2008-07-25
11:06:30) [GET] 
  Session ID: 56f806ed434bfb20f2e37cb433c62220 
  Parameters: {"action"=>"index", "controller"=>"main"} 
Error in main_controller.index: certificate verify failed 
/var/www/fulfillment/public/../config/../lib/http-access2.rb:1001:in
`connect' 
/var/www/fulfillment/public/../config/../lib/http-access2.rb:1001:in
`ssl_connect' 
/var/www/fulfillment/public/../config/../lib/http-access2.rb:1363:in
`connect' 
/usr/local/lib/ruby/1.8/timeout.rb:56:in `timeout' 
/usr/local/lib/ruby/1.8/timeout.rb:76:in `timeout' 
/var/www/fulfillment/public/../config/../lib/http-access2.rb:1351:in
`connect' 
/var/www/fulfillment/public/../config/../lib/http-access2.rb:1209:in
`query' 
/var/www/fulfillment/public/../config/../lib/http-access2.rb:892:in
`query' 
/var/www/fulfillment/public/../config/../lib/http-access2.rb:434:in
`do_get_block' 
/var/www/fulfillment/public/../config/../lib/http-access2.rb:370:in
`conn_request' 
/var/www/fulfillment/public/../config/../lib/http-access2.rb:285:in
`request' 
/var/www/fulfillment/public/../config/../lib/http-access2.rb:264:in
`post' 
/usr/local/lib/ruby/1.8/soap/streamHandler.rb:170:in `send_post' 
/usr/local/lib/ruby/1.8/soap/streamHandler.rb:109:in `send' 
/usr/local/lib/ruby/1.8/soap/rpc/proxy.rb:170:in `route' 
/usr/local/lib/ruby/1.8/soap/rpc/proxy.rb:141:in `call' 
/usr/local/lib/ruby/1.8/soap/rpc/driver.rb:178:in `call' 
/usr/local/lib/ruby/1.8/soap/rpc/driver.rb:232:in `get_unfulfilled' 
/usr/local/lib/ruby/gems/1.8/gems/actionwebservice-1.1.6/lib/action_web_service/client/soap_client.rb:63:in `send' 
/usr/local/lib/ruby/gems/1.8/gems/actionwebservice-1.1.6/lib/action_web_service/client/soap_client.rb:63:in `perform_invocation' 
/usr/local/lib/ruby/gems/1.8/gems/actionwebservice-1.1.6/lib/action_web_service/client/base.rb:15:in `method_missing' 
/var/www/fulfillment/public/../config/../app/controllers/main_controller.rb:35:in `index' 
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/base.rb:941:in `send' 
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/base.rb:941:in `perform_action_without_filters' 
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/filters.rb:368:in `perform_action_without_benchmark' 
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/benchmarking.rb:69:in
`perform_action_without_rescue' 
/usr/local/lib/ruby/1.8/benchmark.rb:293:in `measure' 
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/benchmarking.rb:69:in
`perform_action_without_rescue' 
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/rescue.rb:82:in `perform_action' 
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/base.rb:408:in `send' 
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/base.rb:408:in `process_without_filters' 
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/filters.rb:377:in
`process_without_session_management_support' 
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/session_management.rb:117:in `process' 
/usr/local/lib/ruby/gems/1.8/gems/rails-1.1.6/lib/dispatcher.rb:38:in
`dispatch' 
/var/www/fulfillment/public/dispatch.cgi:10 
Completed in 0.01965 (50 reqs/sec) | Rendering: 0.00006 (0%) | 200 OK 


============Error 2============== 

irb(main):001:0> require 'rubygems' 
=> true 
irb(main):002:0> require 'hpricot' 
NoMethodError: private method `specification_version=' called for
#<Gem::Specification:0xb7c8d1a8> 
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:86:in
`load_specification' 
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/specification.rb:401:in `initialize' 
        from (eval):1:in `new' 
        from (eval):1:in `load_specification' 
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:121:in `eval' 
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:86:in
`load_specification' 
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:121:in `load_gems_in' 
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:120:in `each' 
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:120:in `load_gems_in' 
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:75:in
`from_gems_in' 
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:47:in
`from_installed_gems' 
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems.rb:109:in
`source_index' 
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:111:in `init_gemspecs' 
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:56:in `initialize' 
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:30:in `new' 
        from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:30:in `require' 



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rubygems-developers/attachments/20080728/a20e9cd9/attachment.html>

From drbrain at segment7.net  Tue Jul 29 14:07:30 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Tue, 29 Jul 2008 11:07:30 -0700
Subject: [Rubygems-developers] Rubygems Errors
In-Reply-To: <980325.89173.qm@web53304.mail.re2.yahoo.com>
References: <980325.89173.qm@web53304.mail.re2.yahoo.com>
Message-ID: <5254EC85-F6EB-476A-ABAD-F1EB3605E705@segment7.net>

Please don't send HTML email to this list, it forces non-monospace  
fonts that make program output hard to read.

On Jul 28, 2008, at 14:00 PM, Matt White wrote:

> I recently upgraded a server's rubygems from 0.9.0 to 1.2.0. Upon  
> doing so, one of our apps that uses soap4r thinks all the security  
> certificates it sees are invalid (see Error 1 below).

Are you sure they are still valid and that this isn't just a  
coincidence?

> I tried reverting to 0.9.0,

You really, really, really don't want to do this, RubyGems 0.9.0 and  
earlier allow malicious gems to write files anywhere on the filesystem.

> irb(main):001:0> require 'rubygems'
> => true
> irb(main):002:0> require 'hpricot'
> NoMethodError: private method `specification_version=' called for  
> #<Gem::Specification:0xb7c8d1a8>
>

This method is most definitely not private in 1.2.0.  If you installed  
a gem with 1.2.0 then rolled back to an older rubygems you'll need to  
reinstall those gems.

From whitethunder922 at yahoo.com  Tue Jul 29 14:16:25 2008
From: whitethunder922 at yahoo.com (Matt White)
Date: Tue, 29 Jul 2008 11:16:25 -0700 (PDT)
Subject: [Rubygems-developers] Rubygems Errors
Message-ID: <605954.68879.qm@web53312.mail.re2.yahoo.com>

>> I recently upgraded a server's rubygems from 0.9.0 to 1.2.0. Upon  
>> doing so, one of our apps that uses soap4r thinks all the security  
>> certificates it sees are invalid (see Error 1 below).

> Are you sure they are still valid and that this isn't just a  
> coincidence?

Yes, I'm sure. Plus, the error didn't start showing up in the logs until right after the upgrade to 1.2.0 was made.

>> I tried reverting to 0.9.0,

> You really, really, really don't want to do this, RubyGems 0.9.0 and  
> earlier allow malicious gems to write files anywhere on the filesystem.

Note taken, thanks.

>> irb(main):001:0> require 'rubygems'
>> => true
>> irb(main):002:0> require 'hpricot'
>> NoMethodError: private method `specification_version=' called for  
>> #<Gem::Specification:0xb7c8d1a8>
>>

> This method is most definitely not private in 1.2.0.  If you installed  
> a gem with 1.2.0 then rolled back to an older rubygems you'll need to  
> reinstall those gems.

This is the error I get when I revert to 0.9.0, not in 1.2.0. With 1.2.0, I get the invalid certificate error. I didn't update any gems since making the upgrade. I've disabled certificate verification for the time being as a workaround and kept Rubygems at 1.2.0. Is there perhaps something else I might need to update? Any more information I should give to help diagnose the error? Thanks again.



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rubygems-developers/attachments/20080729/778c62d0/attachment.html>

From drbrain at segment7.net  Tue Jul 29 16:44:33 2008
From: drbrain at segment7.net (Eric Hodel)
Date: Tue, 29 Jul 2008 13:44:33 -0700
Subject: [Rubygems-developers] Rubygems Errors
In-Reply-To: <605954.68879.qm@web53312.mail.re2.yahoo.com>
References: <605954.68879.qm@web53312.mail.re2.yahoo.com>
Message-ID: <5FE9D2F7-CCBC-4ECA-8D64-7EEE0F5CDD00@segment7.net>

On Jul 29, 2008, at 11:16 AM, Matt White wrote:
> >> irb(main):001:0> require 'rubygems'
> >> => true
> >> irb(main):002:0> require 'hpricot'
> >> NoMethodError: private method `specification_version=' called for
> >> #<Gem::Specification:0xb7c8d1a8>
> >>
>
> > This method is most definitely not private in 1.2.0.  If you  
> installed
> > a gem with 1.2.0 then rolled back to an older rubygems you'll need  
> to
> > reinstall those gems.
>
> This is the error I get when I revert to 0.9.0, not in 1.2.0.

Yes, installed gem repositories may not be backwards compatible.

> With 1.2.0, I get the invalid certificate error. I didn't update any  
> gems since making the upgrade. I've disabled certificate  
> verification for the time being as a workaround and kept Rubygems at  
> 1.2.0. Is there perhaps something else I might need to update? Any  
> more information I should give to help diagnose the error? Thanks  
> again.

It's possible that you're using the soap4r gem instead of the built-in  
version depending on which version of RubyGems you're using, beyond  
that I'm not sure.  You'll have to some digging to find out.

From martin.krauskopf at gmail.com  Thu Jul 31 17:43:33 2008
From: martin.krauskopf at gmail.com (Martin Krauskopf)
Date: Thu, 31 Jul 2008 23:43:33 +0200
Subject: [Rubygems-developers] LOCAL/REMOTE tokens are not printed for
	non-tty
Message-ID: <g6tbm5$n1d$1@ger.gmane.org>

Hi all, likely mainly Eric ;),

what was the reason for the change:

   .../rubyforge.org/rubygems$ svn di -r 1834:1835
   ....
   + * lib/rubygems/commands/query_command.rb:  Don't print LOCAL/REMOTE
   + gems if stdout is not a TTY.
   ....

we use LOCAL and REMOTE lines as 'recognition tokens' when parsing
output of the 'gem list <...>' in the Gem Manager in NetBeans Ruby IDE.
So with this change our 'parser' is broken.

Any chance the change will be reverted (e.g. in RubyGems 1.2.1), so the
output remains backward compatible for cases like this?

Thanks,
   m.

PS: I know that parsing of the output is poor solution, we are going to
     switch to pure one using RubyGems API in next versions of the Gem
     Manager