[Ironruby-core] IronRuby version of existing gems

Will Green will at hotgazpacho.org
Sat Mar 6 08:50:19 EST 2010


Yes, that seems to be close to my understanding. Only much more  
eloquently stated. Thank you! :-)

Also keep in mind that not everyone using Ruby uses Ruby Gems. In  
fact, it is considered rude to presume the existance of any library  
package management system by the consumer. So, RUBY_PLATFORM is a more  
important constant to define correctly for platform detection (since  
this IS present for every Ruby implementation).

Now for feature detection, libraries usually do a regex match on  
RUBY_PLATFORM, usually

RUBY_PLATFORM =~ /mswin|mingw/

So, we might define RUBY_PLATFORM as mswin.netX, linux.netX,  
macosx.netX, etc. (where X is the .Net runtime version). However, I  
still think we'll run into libraries that make other assumptions about  
the Ruby runtime that won't be true or IronRuby. Such libraries would  
need to be patched to recognize the extended platform name.

I don't have JRuby installed, and I don't have a Mac to check on,  
either, but perhaps it might provide some guidance to see what JRuby  
defines RUBY_PLATFORM as on the various OSes.

On a side note, thank you Shri, Tomas, and everyone else for taking my  
impassioned pleas for what they truly are: a desire to make IronRuby  
an awesome, well-manored Ruby implementation! Keep up the good work!

--
Will Green
http://hotgazpacho.org/



On Mar 6, 2010, at 1:58 AM, Tomas Matousek  
<Tomas.Matousek at microsoft.com> wrote:

> So basically, if I understand it well, there are two variables in  
> question:
>
> 1)      “native” extension formats supported by particular Ruby  
> VM – that would be MSVC6 compiled PE file/mingw compiled PE file/gcc 
>  compiled .so file for MRI, Java class file for JRuby and CLR assemb 
> ly for IronRuby. Any subsystem that builds/uses “native”  
> extensions needs to use this variable. A particular VM can support m 
> ultiple formats (JRuby supports Java class files and FFI compatible  
> native extensions). This is what Gem::Platform seems to be used for.
>
> 2)      The capabilities of the underlying CPU and OS. This is what  
> RUBY_PLATFORM is used for – behavior of certain APIs like fork, etc, 
>  process, files, etc.  might be different/unavailable on different p 
> latforms.
>
>
>
> Is that correct?
>
> Tomas
>
>
>
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- 
> bounces at rubyforge.org] On Behalf Of Will Green
> Sent: Friday, March 05, 2010 8:18 PM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] IronRuby version of existing gems
>
>
>
> See  http://docs.rubygems.org/read/chapter/20#platform
>
>
>
> Basically, most gems contain pure Ruby code. Some gems contain C (or  
> Java, or now possibly C#) code that gets compiled at gem install  
> time. Some gems even include pre-compiled code. You will find that  
> the overwhelming majority of these gems target the mswin32 platform  
> (which is based on the VC6 runtime).
>
>
>
> The reason that binary gems are distributed is that, unlike on most  
> Linux/UNIX/BSD based systems, Windows does not come with a C  
> compiler, let alone the specific version used to create mswin32  
> Ruby, MSVC 6. So, users of the mswin32 Ruby relied on those who had  
> a license to MSVC 6 to provide binaries of the gems they needed.  
> This is a major reason why development of the mswin32 Ruby has  
> ceased... Very few people have MSVC6, it's old and slow, and those  
> who want MSVC6 (so they can contribute to mswin32 Ruby) can't get it  
> anymore. This is why the mingw32 version of Ruby is the actively  
> maintained version of C Ruby on Windows: no worries about mingw  
> licensing and distribution, and it's freely available.
>
>
>
> This is the reason why it is important that IronRuby report the  
> correct architecture and runtime environment. As I said before, Gems  
> that target mswin32 will not run on IronRuby, because the thing that  
> makes them mswin32 is that they include C extensions that can be, or  
> are, compiled to native, unmanaged code targetting the MSVC6  
> runtime. So, it is important that IronRuby not identify itself as  
> mswin32, because the gems that target that platform won't work on  
> IronRuby anyway.
>
>
>
> What Luis has done with Rake Compiler is allow the gem author to  
> create extensions in C and Java, and permit them to compile platform  
> specific versions of the same gem. I'm sure that he would welcome  
> contributions that would allow us to write extensions in C# and  
> build gems that target IronRuby as a platform, all while keeping the  
> same gem name. That is, win32console-mswin32.gem and win32console- 
> mingw32.gem come from the same source gem, but they are compiled  
> against different runtimes, and target different platforms. With  
> IronRuby identifying itself correctly, and some additions to rake- 
> compiler to generate .Net assemblies, it may be possible to generate  
> a win32console-.net20.gem. Even then, we'd need to provide patches  
> to libraries that use a regex against RUBY_PLATFORM to determine if  
> we're running on Windows. But then, what if you're running IronRuby  
> on Mono on Linux, where any of the win32xxx gems make no sense?
>
>
>
> My point is that I don't see a way to just inject IronRuby-specific  
> libraries in place of the mswin32 ones without causing all sorts of  
> headaches with platform juggling. IronRuby is not always on Windows,  
> and thus should not identify itself as running on Windows, and  
> certainly should not identify itself as the MSVC6 version or Ruby.
>
>
> --
>
> Will Green
>
> http://hotgazpacho.org/
>
>
>
>
>
>
> On Mar 5, 2010, at 8:39 PM, Shri Borde <Shri.Borde at microsoft.com>  
> wrote:
>
> The gem file name does include the platform information. That would  
> seem to imply that gems for different platforms will live in  
> different gem files. I am not too knowledge about the Gem process as  
> well, so I may be incorrect as well…
>
>
>
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- 
> bounces at rubyforge.org] On Behalf Of Will Green
> Sent: Friday, March 05, 2010 9:46 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] IronRuby version of existing gems
>
>
>
> I may not fully understand the Gem process here, so please pardon  
> any ignorance.
>
>
>
> As I understand it, the ability to have separate, per-platform gem  
> files for one Gem name would require that the code for all the  
> platforms is present in the source of the Gem. That way, when you  
> gem install XXX, the XXX library will get compiled locally for your  
> current platform. Or, if the gem author provides them, pre-compiled  
> binaries for your platform. In order to do that, though, I think the  
> source code for multiple platforms needs to be present in the gem  
> source.
>
>
>
> Luis is very knowledgeable in this area; he also wrote rake-compiler  
> to address this issue with JRuby as well: http://github.com/luislavena/rake-compiler
>
>
>
> I think it best to get his perspective on the best way to go about  
> this.
>
>
>
> I am, however, glad that IronRuby is now more truthful about its  
> architecture (since gems compiled for mswin32 WILL NOT WORK on  
> IronRuby). I am certain this will lead to less frustration from end- 
> users going forward.
>
>
> --
> Will Green
> http://hotgazpacho.org/
>
>
>
> On Fri, Mar 5, 2010 at 12:00 PM, Shri Borde  
> <Shri.Borde at microsoft.com> wrote:
>
> The whole point of changing RbConfig::CONFIG[“arch”] was to be  
> able to have two independent gem files. So you should not need to ha 
> ve to modify Luis Lavena’s code, right? And people installing win32c 
> onsole with MRI should not run any of your code, right?
>
>
>
> You could certainly drop him a line as a courtesy heads-up…
>
>
>
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- 
> bounces at rubyforge.org] On Behalf Of Will Green
> Sent: Friday, March 05, 2010 8:11 AM
>
>
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] IronRuby version of existing gems
>
>
>
> I'd have to talk to Luis Lavena, the current maintainer of  
> win32console. I might also have to make some code changes or test  
> changes to make the .Net specific stuff a no-op on the C version of  
> Ruby (otherwise, it won't even run). But I'd certainly be open to  
> this. I'll drop him a line this weekend.
>
>
> --
> Will Green
> http://hotgazpacho.org/
>
> On Fri, Mar 5, 2010 at 10:45 AM, Shri Borde  
> <Shri.Borde at microsoft.com> wrote:
>
> We should push the change once the dust settles down. Let’s wait unt 
> il the RTM to make sure that this all actually works as we would lik 
> e it to.
>
>
>
> In the meantime, I would encourage all gem authors to play with this  
> and see if there are any issues. “gem build” had the issue  
> mentioned below. Not sure if jeweler etc will have any issues.
>
>
>
> Will, will you be renaming iron-term-ansicolor to win32console? Its  
> your call whether you want to or not. However, if you do not, we  
> should create a gem with platform=”universal-.net” and with the  
> same name of a native gem, and see what the experience is (does “ir. 
> exe –S gem install” prefer the .NET gem over the native gem?). I  
> did verify that “ir.exe –S gem install win32console” currently  
> does not find any matching gem since the existing win32console is a  
> native gem.
>
>
>
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- 
> bounces at rubyforge.org] On Behalf Of Will Green
> Sent: Friday, March 05, 2010 7:08 AM
>
>
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] IronRuby version of existing gems
>
>
>
> Cool beans!
>
>
>
> I noticed in the latest push that a change was made to Ruby Gems  
> itself:
>
>
>
> http://github.com/ironruby/ironruby/commit/82cb04621b505dea5a010c70827addc2de6227ba#diff-0
>
>
>
> Someone should contribute that change to the Ruby Gems project as  
> well.
>
>
> --
> Will Green
> http://hotgazpacho.org/
>
> On Thu, Mar 4, 2010 at 7:36 PM, Shri Borde  
> <Shri.Borde at microsoft.com> wrote:
>
> With my last checkin, RbConfig::CONFIG[“arch”] will be  
> “universal-.net2.0” for IronRuby. I created a gemspec as shown  
> below. Doing “gem build” on it will create a gem with filename of  
> Shri-1.2.3-universal-unknown.gem. Instead use “rbx –S gem  
> build” and you will get a file called Shri-1.2.3-universal-.net.gem.
>
>
>
> spec = Gem::Specification.new do |s|
>
>   s.name = 'Shri'
>
>   s.version = '1.2.3'
>
>   s.summary = "Shri summary"
>
>   s.platform = "universal-.net"
>
>   s.description = %{Shri description}
>
>   s.files = []
>
>   s.author = "Shri"
>
>   s.email = "shri at email"
>
>   s.homepage = "http://shri.org"
>
> end
>
>
>
> I have updated with http://ironruby.net/Documentation/Real_Ruby_Applications/RubyGems 
>  with this info:
>
> IronRuby-specific gems
>
> Gems could specifically target IronRuby. They may contain Ruby code  
> which uses .NET APIs, or they may even include compiled .NET  
> assemblies. In such cases, the Gem specification should set platform  
> to "universal-.net" (or "universal-.net4.0" to run only on .NET 4),  
> and build the gem using IronRuby ("rbx -S gem build").
>
> Note that if you build the gem with MRI using "gem build", MRI will  
> not be able to recognize the platform string, and will create a gem  
> file named something like foo-universal-unknown.gem (instead of the  
> expected foo-universal-.net.gem"). To avoid this, build the gem  
> using IronRuby as mentioned above.
>
> Talking with Tomas, we will leave RUBY_PLATFORM set to “x86- 
> mswin32” (on Windows) since many apps check for “mswin32” in  
> RUBY_PLATFORM to check if they are running on Windows. We considered 
>  appending “.net” and setting RUBY_PLATFORM to “.net-mswin32”  
> or “x86-mswin32/.net” to indicate that it was not MRI, but  
> decided against it as you can always check RUBY_ENGINE to detect if  
> you are running on IronRuby.
>
>
>
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- 
> bounces at rubyforge.org] On Behalf Of Will Green
> Sent: Tuesday, March 02, 2010 11:52 AM
>
>
> To: ironruby-core at rubyforge.org
>
> Subject: Re: [Ironruby-core] IronRuby version of existing gems
>
>
>
> That all depends on how Gem checks the platform.  If it uses the  
> RUBY_PLATFORM variable, then IronRuby needs to change what it  
> reports here. Currently, it reports i386-mswin32.
>
>
> --
> Will Green
> http://hotgazpacho.org/
>
> On Tue, Mar 2, 2010 at 1:07 PM, Jim Deville <jdeville at microsoft.com>  
> wrote:
>
> I believe JRuby is doing the 1st one, which makes sense in my  
> opinion. If possible we should prefer platform == “ironruby”,  
> (or .net, do we need to differentiate .net and mono?), but accept ot 
> hers.
>
>  JD
>
>  From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- 
> bounces at rubyforge.org] On Behalf Of Shri Borde
> Sent: Tuesday, March 02, 2010 10:02 AM
> To: ironruby-core at rubyforge.org
> Subject: [Ironruby-core] IronRuby version of existing gems
>
>  This brings a question to mind - what should the general approach  
> be for porting existing gems to IronRuby? There could be two  
> possible approaches:
>
> 1.       Create a gem with the same name (“win32console” in this  
> case), and specify platform==”ironruby”. That way, dependent gems  
> do not need to be updated, and users have to remember just one name. 
>  IronRuby will use the version with platform==”ironruby”, and MRI  
> will use the one with platform==”mswin32”. So there should not be  
> any clashes even if you use MRI and IronRuby on the same machine.
>
> 2.       Create a new gem like iron-term-ansicolor.
>
>
>
> Any pro or cons to the two? What should the recommendation be in  
> general?
>
>
>
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- 
> bounces at rubyforge.org] On Behalf Of Will Green
> Sent: Tuesday, March 02, 2010 7:47 AM
> To: ironruby-core
> Subject: Re: [Ironruby-core] iron-term-ansicolor 0.0.2 Released
>
>
>
> I released iron-term-ansicolor 0.0.3 last night after testing the  
> gem install locally first.
>
>
>
> Please let me know if you still have trouble installing it from Rubygems.org 
> .
>
>
>
> Also, I've submitted a patch to RSpec to use iron-term-ansicolor if  
> it can, the same way it tries to use win32console under MRI.
>
>
> --
> Will Green
> http://hotgazpacho.org/
>
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20100306/6b06c11b/attachment-0001.html>


More information about the Ironruby-core mailing list