From anugupta at pu.ac.in Mon Apr 9 04:46:08 2007 From: anugupta at pu.ac.in (Anu Gupta DCSA) Date: Mon, 9 Apr 2007 15:16:08 +0630 Subject: [Rubygems-developers] A Survey on Defect Management Practices in Free/Open Source Software Message-ID: <20070409084558.M38761@pu.ac.in> Sir/Madam I seek help from designers, developers, testers,defect fixers,project managers or playing any other key role in Free/Open Source software development or maintenence in carrying out a study on practices and problems of defect management in various Free/Open Source Software projects. The insights gained from the study can further help us to extract publicly accessible defect data and determine impact of defect management practices on software quality. Please spend a few minutes of your precious time to fill up the Questionnaire. The most of the questions follow multiple choice formats and are quite easy to answer. To have the Online Questionnaire, please visit: http://anu.puchd.ac.in/phpESP/public/survey.php?name=FOSS_Defect_Survey (You can also copy and paste this link into your browser, and hit the 'Return' key.) I hope you will find all the questions interesting and thought-provoking. Your answers will be kept anonymous.The data thus collected will only be used for research purpose.It would be nice if you may further refer this mail to others actively engaged with Free/Open Source Software development. If you have any query or suggestions then feel free to contact. Thank You With regards, Anu Gupta Senior Lecturer Department of Computer Science and Applications, Panjab University, Chandigarh. INDIA In case of any problem in accessing/using the above mentioned link please contact: E-mail: anugupta at pu.ac.in anugupta98 at gmail.com From anugupta at pu.ac.in Tue Apr 10 01:27:54 2007 From: anugupta at pu.ac.in (Anu Gupta DCSA) Date: Tue, 10 Apr 2007 11:57:54 +0630 Subject: [Rubygems-developers] A Study on Free/Open Source Software Defect Management Message-ID: <20070410052736.M53275@pu.ac.in> Dear Rubygems Contributots, I am really thankful to Free/Open Source Software development community for their overwhelming response to the survey on practices and problems of defect management in Free/Open Source Software projects. If you have not participated ealier, you may spend a few minutes now too. The Online Questionnaire is available at: http://anu.puchd.ac.in/phpESP/public/survey.php?name=FOSS_Defect_Survey I hope you have found all the questions interesting and thought-provoking. Your answers will be kept anonymous.The data thus collected will only be used for research purpose. The insights gained from the study can further help us to extract publicly accessible defect data and determine impact of defect management practices on software quality. The results of study will soon be communicated to you. Thank You With regards, Anu Gupta Senior Lecturer Department of Computer Science and Applications, Panjab University, Chandigarh. INDIA In case of any problem in accessing/using the above mentioned link please contact: E-mail: anugupta at pu.ac.in anugupta98 at gmail.com From avatar at spellboundnet.com Tue Apr 10 12:06:00 2007 From: avatar at spellboundnet.com (Donavan Pantke) Date: Tue, 10 Apr 2007 12:06:00 -0400 Subject: [Rubygems-developers] [PATCH] Fix configure test Message-ID: <200704101206.00415.avatar@spellboundnet.com> I noticed when running the test suite on my Linux machine, the test that checked for the failure to run ./configure wasn't working right. Not sure if the Mac shells handle this differently, but here's a patch to make them work correctly on Linux: Index: test_gem_ext_configure_builder.rb =================================================================== --- test_gem_ext_configure_builder.rb (revision 1225) +++ test_gem_ext_configure_builder.rb (working copy) @@ -51,14 +51,14 @@ expected = "configure failed: sh ./configure --prefix=#{@dest_path} -./configure: ./configure: No such file or directory +sh: ./configure: No such file or directory " assert_equal expected, error.message expected = [ "sh ./configure --prefix=#{@dest_path}", - "./configure: ./configure: No such file or directory\n" + "sh: ./configure: No such file or directory\n" ] assert_equal expected, output From drbrain at segment7.net Tue Apr 10 13:57:27 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 10 Apr 2007 10:57:27 -0700 Subject: [Rubygems-developers] [PATCH] Fix configure test In-Reply-To: <200704101206.00415.avatar@spellboundnet.com> References: <200704101206.00415.avatar@spellboundnet.com> Message-ID: <2DBC0C88-9F99-4718-BCE5-D6F6C90D82C1@segment7.net> On Apr 10, 2007, at 09:06, Donavan Pantke wrote: > I noticed when running the test suite on my Linux machine, the test > that > checked for the failure to run ./configure wasn't working right. > Not sure if > the Mac shells handle this differently, but here's a patch to make > them work > correctly on Linux: You'll need to submit this patch to the tracker on Rubyforge, otherwise its sure to get lost. From m.zecko at gmail.com Wed Apr 11 04:27:15 2007 From: m.zecko at gmail.com (m.zeckinger) Date: Wed, 11 Apr 2007 10:27:15 +0200 Subject: [Rubygems-developers] repackaging rubygems and no such file to load -- rubygems (LoadError) Message-ID: <8be6656c0704110127nf627259o9b97bc266334e2e4@mail.gmail.com> hello guys, i came across the part in you faq that says "No such file to load?rubygems", because i experience the same problem. your answer still didn't tell me much about what can be the real problem there. i am currently trying to repackage software on osx, (ruby and rubygems), to be included in an installer-package. how would i install rubygems in this case? i tried it the following way: ruby setup.rb config --prefix=/usr/local ruby setup.rb install --prefix=/UB/compile/Distribution_folder/Package_Root/usr/local but still, when i install the package on another system, i get the errors. /usr/local/bin/gem:9:in `require': no such file to load -- rubygems (LoadError) from /usr/local/bin/gem:9 another try: PREFIX="/UB/compile/Distribution_folder/Package_Root/usr/local" GEM_HOME=$PREFIX/lib/ruby/gems/1.8 RUBYLIB=$PREFIX/lib/ruby:$PREFIX/lib/site_ruby/1.8 ruby setup.rb config --prefix=/usr/local ruby setup.rb install --prefix=$PREFIX then i tried to deinstall my local ruby and building from the just freshly compiled ruby, via $PREFIX/bin/ruby setup.rb config --prefix=/usr/local $PREFIX/bin/ruby setup.rb install --prefix=$PREFIX which resulted in another problem: dyld: Symbol not found: _ruby_init_stack Referenced from: /UB/compile/Distribution_folder/Package_Root/usr/local/bin/ruby Expected in: /usr/lib/libruby.dylib this obviously doesn't work, since i cannot install rubygems from the not-yet-installed ruby. please, guys, can you make this more clear and tell me what to do to repackage rubygems? thanks a lot! mz From thewoolleyman at gmail.com Wed Apr 11 23:32:57 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Wed, 11 Apr 2007 20:32:57 -0700 Subject: [Rubygems-developers] repackaging rubygems and no such file to load -- rubygems (LoadError) In-Reply-To: <8be6656c0704110127nf627259o9b97bc266334e2e4@mail.gmail.com> References: <8be6656c0704110127nf627259o9b97bc266334e2e4@mail.gmail.com> Message-ID: Here's what I do to make a test installation of rubygems: class RubyGemsInstaller attr_writer :install_dir attr_writer :rubygems_dist_dir def install install_dir = File.expand_path(@install_dir) rubygems_dist_dir = File.expand_path(@rubygems_dist_dir) ENV['GEM_HOME'] = "#{install_dir}" setup_cmd = "ruby setup.rb" Dir.chdir("#{rubygems_dist_dir}") do `#{setup_cmd} config --prefix=#{install_dir}` `#{setup_cmd} setup` `#{setup_cmd} install` end end end ...although I've never done this on a system without rubygems already installed, and I still end up using the executables from the main installation. -- Chad On 4/11/07, m. zeckinger wrote: > hello guys, i came across the part in you faq that says "No such file > to load?rubygems", because i experience the same problem. > your answer still didn't tell me much about what can be the real > problem there. i am currently trying to repackage software on osx, > (ruby and rubygems), to be included in an installer-package. > how would i install rubygems in this case? > i tried it the following way: > > ruby setup.rb config --prefix=/usr/local > ruby setup.rb install > --prefix=/UB/compile/Distribution_folder/Package_Root/usr/local > > but still, when i install the package on another system, i get the errors. > /usr/local/bin/gem:9:in `require': no such file to load -- rubygems (LoadError) > from /usr/local/bin/gem:9 > > > another try: > PREFIX="/UB/compile/Distribution_folder/Package_Root/usr/local" > GEM_HOME=$PREFIX/lib/ruby/gems/1.8 > RUBYLIB=$PREFIX/lib/ruby:$PREFIX/lib/site_ruby/1.8 > > ruby setup.rb config --prefix=/usr/local > ruby setup.rb install --prefix=$PREFIX > > then i tried to deinstall my local ruby and building from the just > freshly compiled ruby, via > > $PREFIX/bin/ruby setup.rb config --prefix=/usr/local > $PREFIX/bin/ruby setup.rb install --prefix=$PREFIX > > which resulted in another problem: > dyld: Symbol not found: _ruby_init_stack > Referenced from: > /UB/compile/Distribution_folder/Package_Root/usr/local/bin/ruby > Expected in: /usr/lib/libruby.dylib > > this obviously doesn't work, since i cannot install rubygems from the > not-yet-installed ruby. > please, guys, can you make this more clear and tell me what to do to > repackage rubygems? > > thanks a lot! > mz > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From gmiller at marketcetera.com Fri Apr 13 13:59:09 2007 From: gmiller at marketcetera.com (Graham Miller) Date: Fri, 13 Apr 2007 10:59:09 -0700 Subject: [Rubygems-developers] Building native gems for deployment Message-ID: <96c48fe10704131059p3151544cmddd4ea36a0ec1c08@mail.gmail.com> Hello all, Sorry if this is the wrong forum, but I thought if anyone would know the answer to this, you guys would... We have a situation where we need to deploy gems that include native code onto a machine that does not have gcc or make installed. The specific situation is that we are creating a VMWare appliance ( http://trac.marketcetera.org/trac.fcgi/wiki/Marketcetera/Appliance ) and we are trying to avoid adding the many many megabytes of native development tools. In the past we have been able to install the gems on the appliance by taking advantage of the fact that "gem" would proceed with installation of the gems (in this case mongrel and fastthread) despite a failure in the native compilation. Then we just copied the native libraries to the appropriate place from a development machine. However it seems that the latest gem release has fixed this, and native gem installations now fail if gcc or make is not present. So I guess my question would be: what is the best way to install a gem onto a machine without having to do the native compilation step? Thanks in advance for any help. graham -- Marketcetera Trading Platform download.run.trade. www.marketcetera.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20070413/2dc513c5/attachment.html From lyle.johnson at gmail.com Fri Apr 13 14:54:23 2007 From: lyle.johnson at gmail.com (Lyle Johnson) Date: Fri, 13 Apr 2007 13:54:23 -0500 Subject: [Rubygems-developers] Building native gems for deployment In-Reply-To: <96c48fe10704131059p3151544cmddd4ea36a0ec1c08@mail.gmail.com> References: <96c48fe10704131059p3151544cmddd4ea36a0ec1c08@mail.gmail.com> Message-ID: On 4/13/07, Graham Miller wrote: > So I guess my question would be: what is the best way to install a gem onto > a machine without having to do the native compilation step? A "binary" gem (i.e. one that contains pre-compiled code for a specific platform) really isn't all that different from a regular gem. In the Gem spec for your binary gem, you'll want to set the platform to the targeted platform, e.g. Gem::Specification.new do |spec| ... spec.platform = Gem::Platform::WIN32 ... end The Gem::Platform module defines a couple of standard constants (WIN32, LINUX_586 and DARWIN), but it's just a string, so put whatever makes sense for the appliance platform that you're targeting. You'll need to add to the spec.files definition the binary files that you want to include (e.g. the *.so files). You can of course remove the source code from spec.files too. You should probably remove the spec.extensions definition altogether. Note that when you build a gem with some platform other than RUBY (the default), you're going to get a gem whose file name reflects the target platform (e.g. "fxruby-1.6.10-mswin32.gem"). Hope this helps, Lyle From transfire at gmail.com Mon Apr 16 13:21:38 2007 From: transfire at gmail.com (TRANS) Date: Mon, 16 Apr 2007 13:21:38 -0400 Subject: [Rubygems-developers] methdos for active?, gemspec and location Message-ID: <4b6f054f0704161021w6f7304gffefe3f6edaae048@mail.gmail.com> Does RubyGems have means for determining if a gem is active or not? And a way to get it's gemspec and locating it's files? I had written these extensions for doing so sometime ago. Hopefully there are built-in ways for accessing such information and these aren't of use anymore. Otherwise perhaps they could be used to provide that access. module Gem # Is a gem active? def self.active?(gemname) @loaded_specs ||= Hash.new @loaded_specs.key? gemname end # path to active gem's files def self.gempath(gemname, subdir=nil) if active?(gemname) if subdir File.join( @loaded_specs[gemname].full_gem_path, subdir ) else @loaded_specs[gemname].full_gem_path end end end # an active gems gemspec def self.gemspec(gemname) @loaded_specs[gemname] if active?(gemname) end end From weyus at att.net Tue Apr 17 14:08:49 2007 From: weyus at att.net (Wes Gamble) Date: Tue, 17 Apr 2007 13:08:49 -0500 Subject: [Rubygems-developers] rubygems.org is down Message-ID: <46250D31.9050408@att.net> All, I'm trying to get to the rubygems user guide and rubygems.org is down. Any idea when it will be back up? Any alternative sites where I can get to the user guide? Thanks, Wes From discordantus at gmail.com Tue Apr 17 15:17:10 2007 From: discordantus at gmail.com (Mark Hubbart) Date: Tue, 17 Apr 2007 12:17:10 -0700 Subject: [Rubygems-developers] repackaging rubygems and no such file to load -- rubygems (LoadError) In-Reply-To: References: <8be6656c0704110127nf627259o9b97bc266334e2e4@mail.gmail.com> Message-ID: Hi, I am working with those who are trying to package rubygems (for a gui installation package on OSX) and I think I may have found a bug in the post-install hook (which installs the "sources" gem). It seems that the post-install hook doesn't honor the install-prefix (in @options['install-prefix']). So doing this: ruby setup.rb config --prefix=/usr/local ruby setup install --prefix=../stage ...installs rubygems in ../stage/usr/local/, but automatically installs the sources gem is in /usr/local/. I'm working on a patch for this, hopefully I'll have time to figure out exactly what's going on here (my first couple fixes didn't work.) cheers, Mark On 4/11/07, Chad Woolley wrote: > Here's what I do to make a test installation of rubygems: > > class RubyGemsInstaller > attr_writer :install_dir > attr_writer :rubygems_dist_dir > > def install > install_dir = File.expand_path(@install_dir) > rubygems_dist_dir = File.expand_path(@rubygems_dist_dir) > ENV['GEM_HOME'] = "#{install_dir}" > setup_cmd = "ruby setup.rb" > Dir.chdir("#{rubygems_dist_dir}") do > `#{setup_cmd} config --prefix=#{install_dir}` > `#{setup_cmd} setup` > `#{setup_cmd} install` > end > end > end > > ...although I've never done this on a system without rubygems already > installed, and I still end up using the executables from the main > installation. > > -- Chad > > On 4/11/07, m. zeckinger wrote: > > hello guys, i came across the part in you faq that says "No such file > > to load?rubygems", because i experience the same problem. > > your answer still didn't tell me much about what can be the real > > problem there. i am currently trying to repackage software on osx, > > (ruby and rubygems), to be included in an installer-package. > > how would i install rubygems in this case? > > i tried it the following way: > > > > ruby setup.rb config --prefix=/usr/local > > ruby setup.rb install > > --prefix=/UB/compile/Distribution_folder/Package_Root/usr/local > > > > but still, when i install the package on another system, i get the errors. > > /usr/local/bin/gem:9:in `require': no such file to load -- rubygems (LoadError) > > from /usr/local/bin/gem:9 > > > > > > another try: > > PREFIX="/UB/compile/Distribution_folder/Package_Root/usr/local" > > GEM_HOME=$PREFIX/lib/ruby/gems/1.8 > > RUBYLIB=$PREFIX/lib/ruby:$PREFIX/lib/site_ruby/1.8 > > > > ruby setup.rb config --prefix=/usr/local > > ruby setup.rb install --prefix=$PREFIX > > > > then i tried to deinstall my local ruby and building from the just > > freshly compiled ruby, via > > > > $PREFIX/bin/ruby setup.rb config --prefix=/usr/local > > $PREFIX/bin/ruby setup.rb install --prefix=$PREFIX > > > > which resulted in another problem: > > dyld: Symbol not found: _ruby_init_stack > > Referenced from: > > /UB/compile/Distribution_folder/Package_Root/usr/local/bin/ruby > > Expected in: /usr/lib/libruby.dylib > > > > this obviously doesn't work, since i cannot install rubygems from the > > not-yet-installed ruby. > > please, guys, can you make this more clear and tell me what to do to > > repackage rubygems? > > > > thanks a lot! > > mz > > _______________________________________________ > > Rubygems-developers mailing list > > Rubygems-developers at rubyforge.org > > http://rubyforge.org/mailman/listinfo/rubygems-developers > > > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > From darix at web.de Tue Apr 17 16:20:02 2007 From: darix at web.de (Marcus Rueckert) Date: Tue, 17 Apr 2007 22:20:02 +0200 Subject: [Rubygems-developers] repackaging rubygems and no such file to load -- rubygems (LoadError) In-Reply-To: References: <8be6656c0704110127nf627259o9b97bc266334e2e4@mail.gmail.com> Message-ID: <20070417202002.GH22086@pixel.global-banlist.de> On 2007-04-17 12:17:10 -0700, Mark Hubbart wrote: > ruby setup.rb config --prefix=/usr/local > ruby setup install --prefix=../stage > > ...installs rubygems in ../stage/usr/local/, but automatically > installs the sources gem is in /usr/local/. maybe prefix is used differently in install and config? darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From cmcknight at cjtechsolutions.com Tue Apr 17 17:06:14 2007 From: cmcknight at cjtechsolutions.com (Charles McKnight) Date: Tue, 17 Apr 2007 14:06:14 -0700 Subject: [Rubygems-developers] Rubygems website down? (slightly OT) Message-ID: Hi All, Anyone know what's up with the rubygems web site? I'm getting the following: Status: 500 Internal Server Error Content-Type: text/html Application error (Apache) Change this error message for exceptions thrown outside of an action (like in Dispatcher setups or broken Ruby code) in public/500.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20070417/2953093d/attachment.html From chad at chadfowler.com Wed Apr 18 00:03:14 2007 From: chad at chadfowler.com (Chad Fowler) Date: Tue, 17 Apr 2007 23:03:14 -0500 Subject: [Rubygems-developers] rubygems.org is down In-Reply-To: <46250D31.9050408@att.net> References: <46250D31.9050408@att.net> Message-ID: On 4/17/07, Wes Gamble wrote: > All, > > I'm trying to get to the rubygems user guide and rubygems.org is down. > Any idea when it will be back up? > Fixed, thanks. Chad From charles.nutter at sun.com Tue Apr 17 23:52:02 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Tue, 17 Apr 2007 22:52:02 -0500 Subject: [Rubygems-developers] Specifying equivalent modules? Message-ID: <462595E2.8070008@sun.com> Is there a way in RubyGems today to specify that one of a number of modules would be considered equivalent, and to load whichever is actually present? So that during install, options could be presented for multiple named gems that provide the same functionality? The reason I ask is that more and more we're seeing gems with C components being ported to Java for use in JRuby. In general, these modules can be re-released under a new name (rmagickjr, jparsetree) and work just fine in isolation. However, since gem dependencies are specified by name, these ports frequently won't be useful when installing a group of modules. Take Mongrel for example. There's a working port of the Ragel code for Mongrel that would allow a gem to be published for JRuby. But we don't like having to hassle Zed to publish code he doesn't own, and it doesn't seem like it should have to be his responsibility. But any gems that depend on Mongrel depend on Mongrel alone, and there's no way to have them load "JMongrel" instead. They'll either succeed to install Mongrel or they'll fail...and generally they fail since there's native code involved we can't run in JRuby. So what's the answer to this problem? At the moment, there are at least four modules being used by JRubyists that have non-Ruby components: - Hpricot, for which _why has published a JRuby gem on his local repository - Mongrel, which is working and has all the pieces ready to go if we could get it published somewhere - JParseTree, which is working, published, and up-to-date with current JRuby, but which can't be installed where dependencies on "parsetree" are specified - RMagicJr, which has much of RMagick's functionality and has been published, but which again can't be installed where dependencies on "rmagick" are specified. So it seems like we need some other option for specifying dependencies or specifying that one released module can substitute for another. Ideas? - Charlie From phurley at gmail.com Wed Apr 18 00:14:01 2007 From: phurley at gmail.com (Patrick Hurley) Date: Wed, 18 Apr 2007 00:14:01 -0400 Subject: [Rubygems-developers] Building native gems for deployment In-Reply-To: <96c48fe10704131059p3151544cmddd4ea36a0ec1c08@mail.gmail.com> References: <96c48fe10704131059p3151544cmddd4ea36a0ec1c08@mail.gmail.com> Message-ID: <554ac39c0704172114x14452e90pe5116a60f7d361b4@mail.gmail.com> On 4/13/07, Graham Miller wrote: > So I guess my question would be: what is the best way to install a gem onto > a machine without having to do the native compilation step? I had a similar problem, with very little testing (so far), try this script, if you have any problems let me know. pth --------------------------------------------- #!/usr/bin/env ruby -w require "rbconfig" require "rubygems" require "pp" require "tmpdir" require "find" require "fileutils" Gem.manage_gems unless gem = ARGV.first puts "You must provide the name of a gem on the command line." exit 1 end gi = Gem::Installer.new(gem) format = Gem::Format.from_file_by_path(gem) dir = File.join(Dir.tmpdir, "gembuilder") FileUtils.rm_r(dir) rescue nil puts "Unpacking gem" gi.unpack(dir) gi.build_extensions(dir, format.spec) files = [] Find.find(dir) do |fname| next if fname == dir files << fname.sub(Regexp.quote(dir+"/"),'') end spec = format.spec spec.extensions = [] spec.files += (files - format.spec.files) spec.platform = Config::CONFIG['arch'].sub(/[\.0-9]*$/, '') puts "Building gem in #{dir}" start_dir = Dir.pwd Dir.chdir(dir) do gb = Gem::Builder.new(spec) gb.build FileUtils.mv Dir.glob("*.gem"), start_dir end puts "Cleaning up #{dir}" FileUtils.rm_rf(dir) From public at bagotricks.com Wed Apr 18 00:15:55 2007 From: public at bagotricks.com (Thomas Palmer) Date: Tue, 17 Apr 2007 21:15:55 -0700 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: <462595E2.8070008@sun.com> References: <462595E2.8070008@sun.com> Message-ID: <46259B7B.4040302@bagotricks.com> If you install multiple versions of the same gem for different platforms in the same repo, you get that menu automatically. So it's safe, but it complicates life for the majority of Ruby users. It doesn't just pick up the right version automatically. Users have to manually choose every time. So maybe JRuby should get its own additional default repo that it checks before going to RubyForge? And only JRuby versions would be installed there? I'm not sure if that's the best solution (or if it would even work since I haven't tested it), but it seems a possibility. But as Tim Hunter pointed out for RMagick, there's some value in people knowing that they don't have the real thing if feature parity isn't there (or big bugs are). So I'll follow his recommendation for now (even if there's no official trademark on RMagick - which you could argue infringes on ImageMagick anyway) with respect to my clone. - Tom Charles Oliver Nutter wrote: > Is there a way in RubyGems today to specify that one of a number of > modules would be considered equivalent, and to load whichever is > actually present? So that during install, options could be presented for > multiple named gems that provide the same functionality? > > The reason I ask is that more and more we're seeing gems with C > components being ported to Java for use in JRuby. In general, these > modules can be re-released under a new name (rmagickjr, jparsetree) and > work just fine in isolation. However, since gem dependencies are > specified by name, these ports frequently won't be useful when > installing a group of modules. > > Take Mongrel for example. There's a working port of the Ragel code for > Mongrel that would allow a gem to be published for JRuby. But we don't > like having to hassle Zed to publish code he doesn't own, and it doesn't > seem like it should have to be his responsibility. But any gems that > depend on Mongrel depend on Mongrel alone, and there's no way to have > them load "JMongrel" instead. They'll either succeed to install Mongrel > or they'll fail...and generally they fail since there's native code > involved we can't run in JRuby. > > So what's the answer to this problem? At the moment, there are at least > four modules being used by JRubyists that have non-Ruby components: > > - Hpricot, for which _why has published a JRuby gem on his local repository > - Mongrel, which is working and has all the pieces ready to go if we > could get it published somewhere > - JParseTree, which is working, published, and up-to-date with current > JRuby, but which can't be installed where dependencies on "parsetree" > are specified > - RMagicJr, which has much of RMagick's functionality and has been > published, but which again can't be installed where dependencies on > "rmagick" are specified. > > So it seems like we need some other option for specifying dependencies > or specifying that one released module can substitute for another. Ideas? > > - Charlie > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > > From public at bagotricks.com Wed Apr 18 00:21:04 2007 From: public at bagotricks.com (Thomas Palmer) Date: Tue, 17 Apr 2007 21:21:04 -0700 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: <46259B7B.4040302@bagotricks.com> References: <462595E2.8070008@sun.com> <46259B7B.4040302@bagotricks.com> Message-ID: <46259CB0.6020705@bagotricks.com> Another option would be to make "gem install" by default pick up the gem for the matching platform unless you specify that you want to choose. Also, it would be _great_ to be able to install multiple versions of the same gem in the local gem home and have each platform know which one it needs to pick up due to configuration at install time (i.e., which ruby installed which gem - or according to later reconfiguration if performed). Anyway, I'm also looking forward to hearing from official RubyGems developers on this. Thanks in advance. - Tom From jim.weirich at gmail.com Wed Apr 18 00:35:25 2007 From: jim.weirich at gmail.com (Jim Weirich) Date: Wed, 18 Apr 2007 00:35:25 -0400 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: <462595E2.8070008@sun.com> References: <462595E2.8070008@sun.com> Message-ID: On 4/17/07, Charles Oliver Nutter wrote: > Is there a way in RubyGems today to specify that one of a number of > modules would be considered equivalent, and to load whichever is > actually present? So that during install, options could be presented for > multiple named gems that provide the same functionality? Would it work to just make platform dependent variants of the gems in question? Currently, RubyGems will make you manually choose the right platform (future versions will autoselect the correct platform for you). Allowing a user to specify an "equivalent" gem is an interesting idea. I would not like to see it at gem definition time tho, I would rather have it happen at installation time. But what would constitute equivalent? Gems works pretty hard at keeping versions correct in dependencies. Would equivalent gems have to have synchronized versions, or would we specify that version 1.0 of JXxxx is equivalent to version 2.3 of RXxxx? That could get confusing quickly. -- -- Jim Weirich jim at weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) From charles.nutter at sun.com Wed Apr 18 01:01:01 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Wed, 18 Apr 2007 00:01:01 -0500 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: References: <462595E2.8070008@sun.com> Message-ID: <4625A60D.4090109@sun.com> Jim Weirich wrote: > On 4/17/07, Charles Oliver Nutter wrote: >> Is there a way in RubyGems today to specify that one of a number of >> modules would be considered equivalent, and to load whichever is >> actually present? So that during install, options could be presented for >> multiple named gems that provide the same functionality? > > Would it work to just make platform dependent variants of the gems in > question? Currently, RubyGems will make you manually choose the right > platform (future versions will autoselect the correct platform for > you). I think it's more than just choosing the right platform...it's an issue that if every gem out there depends on "mongrel" there's not a thing we can do to force them to install and run with "jmongrel", even if the two are nearly identical. > Allowing a user to specify an "equivalent" gem is an interesting idea. > I would not like to see it at gem definition time tho, I would rather > have it happen at installation time. But what would constitute > equivalent? Gems works pretty hard at keeping versions correct in > dependencies. Would equivalent gems have to have synchronized > versions, or would we specify that version 1.0 of JXxxx is equivalent > to version 2.3 of RXxxx? That could get confusing quickly. I agree it could get very confusing. Obviously the simplest answer is that for a given module name, we should have a gem each for every supported platform. But in reality that puts a lot of burden on the owner of that name, especially when we're looking at more and more ports to JRuby that the original C extension authors are unlikely to want to maintain. Perhaps there's a way a gem publisher could specify "my gem Y is equivalent to gem X" so that any apps depending on gem X could successfully install with gem Y. I've no concerns about pushing that management onto the port developers, since it removes the burden from the original gem authors. I'd hate to think we've got an unfixable problem where only the "in crowd" of C-based gems will ever get to play the game, but with hard name-based dependencies it's going to be more and more difficult for gem ports to swap in seamlessly...even when the swap might be the only way that gem will work on a given implementation. - Charlie From charles.nutter at sun.com Wed Apr 18 01:03:39 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Wed, 18 Apr 2007 00:03:39 -0500 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: <46259B7B.4040302@bagotricks.com> References: <462595E2.8070008@sun.com> <46259B7B.4040302@bagotricks.com> Message-ID: <4625A6AB.3080809@sun.com> Thomas Palmer wrote: > But as Tim Hunter pointed out for RMagick, there's some value in people > knowing that they don't have the real thing if feature parity isn't > there (or big bugs are). So I'll follow his recommendation for now (even > if there's no official trademark on RMagick - which you could argue > infringes on ImageMagick anyway) with respect to my clone. Well, I suppose the problem with this logic is that no interpreter in the world can run both RMagick and RMagickJr at the same time. You can either run one or the other, but not both. So saying that C or JRuby users might want to ensure they have the "real thing" doesn't really apply...the "real thing" for JRuby users won't work at all, and the Java-based version won't work for C Ruby users. Keep in mind this largely just applies to cases where we have a Java port of a C-extension-based gem...those cases present zero conflict between platforms, so the only "real thing" is the one that will actually work... - Charlie From darix at web.de Wed Apr 18 06:36:52 2007 From: darix at web.de (Marcus Rueckert) Date: Wed, 18 Apr 2007 12:36:52 +0200 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: References: <462595E2.8070008@sun.com> Message-ID: <20070418103652.GJ22086@pixel.global-banlist.de> On 2007-04-18 00:35:25 -0400, Jim Weirich wrote: > On 4/17/07, Charles Oliver Nutter wrote: > > Is there a way in RubyGems today to specify that one of a number of > > modules would be considered equivalent, and to load whichever is > > actually present? So that during install, options could be presented for > > multiple named gems that provide the same functionality? > > Would it work to just make platform dependent variants of the gems in > question? Currently, RubyGems will make you manually choose the right > platform (future versions will autoselect the correct platform for > you). > > Allowing a user to specify an "equivalent" gem is an interesting idea. > I would not like to see it at gem definition time tho, I would rather > have it happen at installation time. But what would constitute > equivalent? Gems works pretty hard at keeping versions correct in > dependencies. Would equivalent gems have to have synchronized > versions, or would we specify that version 1.0 of JXxxx is equivalent > to version 2.3 of RXxxx? That could get confusing quickly. rpm allows you to use "Provides" for such problems: so JXxxx.rpm would have "Provides: RXxxx = 2.3". By default every package provides its "name = version-release". (the version-release string can be matched partially) so another gem/rpm would have "Requires: RXxxx = 2.3" and the installer/package manager would offer you to install one of them maybe that could be done with gem too. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From lyle.johnson at gmail.com Wed Apr 18 08:13:14 2007 From: lyle.johnson at gmail.com (Lyle Johnson) Date: Wed, 18 Apr 2007 07:13:14 -0500 Subject: [Rubygems-developers] RubyGems 0.9.2 on Ruby 1.9? Message-ID: Apologies if this has been addressed before; I did a quick search of the rubygems-developers mailing list but couldn't find anything. I'm trying to install rubygems-0.9.2 under Ruby 1.9 (latest code from the trunk), and it stops with: Successfully built RubyGem Name: sources Version: 0.0.1 File: sources-0.0.1.gem hook /Users/lyle/src/rubygems-0.9.2/./post-install.rb failed: gzip error installing sources-0.0.1.gem Is there any way to work around this? Thanks, Lyle From darix at web.de Wed Apr 18 09:38:12 2007 From: darix at web.de (Marcus Rueckert) Date: Wed, 18 Apr 2007 15:38:12 +0200 Subject: [Rubygems-developers] RubyGems 0.9.2 on Ruby 1.9? In-Reply-To: References: Message-ID: <20070418133812.GK22086@pixel.global-banlist.de> On 2007-04-18 07:13:14 -0500, Lyle Johnson wrote: > Apologies if this has been addressed before; I did a quick search of > the rubygems-developers mailing list but couldn't find anything. > > I'm trying to install rubygems-0.9.2 under Ruby 1.9 (latest code from > the trunk), and it stops with: > > Successfully built RubyGem > Name: sources > Version: 0.0.1 > File: sources-0.0.1.gem > hook /Users/lyle/src/rubygems-0.9.2/./post-install.rb failed: > gzip error installing sources-0.0.1.gem > > Is there any way to work around this? ruby is build with zlib support? darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org From lyle.johnson at gmail.com Wed Apr 18 09:52:36 2007 From: lyle.johnson at gmail.com (Lyle Johnson) Date: Wed, 18 Apr 2007 08:52:36 -0500 Subject: [Rubygems-developers] RubyGems 0.9.2 on Ruby 1.9? In-Reply-To: <20070418133812.GK22086@pixel.global-banlist.de> References: <20070418133812.GK22086@pixel.global-banlist.de> Message-ID: On 4/18/07, Marcus Rueckert wrote: > ruby is build with zlib support? It seems to be: irb(main):001:0> RUBY_VERSION => "1.9.0" irb(main):002:0> require 'zlib' => true -- Lyle From mfp at acm.org Wed Apr 18 09:59:45 2007 From: mfp at acm.org (Mauricio Fernandez) Date: Wed, 18 Apr 2007 15:59:45 +0200 Subject: [Rubygems-developers] RubyGems 0.9.2 on Ruby 1.9? In-Reply-To: References: Message-ID: <20070418135945.GK17734@tux-chan> On Wed, Apr 18, 2007 at 07:13:14AM -0500, Lyle Johnson wrote: > Apologies if this has been addressed before; I did a quick search of > the rubygems-developers mailing list but couldn't find anything. > > I'm trying to install rubygems-0.9.2 under Ruby 1.9 (latest code from > the trunk), and it stops with: > > Successfully built RubyGem > Name: sources > Version: 0.0.1 > File: sources-0.0.1.gem > hook /Users/lyle/src/rubygems-0.9.2/./post-install.rb failed: > gzip error installing sources-0.0.1.gem > > Is there any way to work around this? AFAIK the code in the svn repos will not work with 1.9, but moriq (Kazuhiro Yoshida) has created a branch that runs on 1.9[1], take a look at http://collaboa.moriq.com/rubygems-for-ruby-1-9/repository/changesets [1] this is what he used to install & benchmark parts of Rails under 1.9, see http://eigenclass.org/hiki/non-synthetic-benchmarks-for-yarv -- Mauricio Fernandez - http://eigenclass.org - singular Ruby ** Latest postings ** simplefold: better vim folding (Ruby, Objective Caml, Perl, PHP, Java) http://eigenclass.org/hiki/simplefold evil.rb wants love http://eigenclass.org/hiki/evil.rb-wants-love From lyle.johnson at gmail.com Wed Apr 18 10:17:29 2007 From: lyle.johnson at gmail.com (Lyle Johnson) Date: Wed, 18 Apr 2007 09:17:29 -0500 Subject: [Rubygems-developers] RubyGems 0.9.2 on Ruby 1.9? In-Reply-To: <20070418135945.GK17734@tux-chan> References: <20070418135945.GK17734@tux-chan> Message-ID: On 4/18/07, Mauricio Fernandez wrote: > AFAIK the code in the svn repos will not work with 1.9, but moriq (Kazuhiro > Yoshida) has created a branch that runs on 1.9[1], take a look at > > http://collaboa.moriq.com/rubygems-for-ruby-1-9/repository/changesets Do you know how can I check out this branch? I've tried a few things along the lines of: svn checkout \ http://collaboa.moriq.com/rubygems-for-ruby-1-9/repository/trunk \ rubygems-for-ruby-1.9 but haven't hit on the correct URL yet (and I can't find any pointers on the site itself). From mfp at acm.org Wed Apr 18 11:37:51 2007 From: mfp at acm.org (Mauricio Fernandez) Date: Wed, 18 Apr 2007 17:37:51 +0200 Subject: [Rubygems-developers] RubyGems 0.9.2 on Ruby 1.9? In-Reply-To: References: <20070418135945.GK17734@tux-chan> Message-ID: <20070418153751.GL17734@tux-chan> On Wed, Apr 18, 2007 at 09:17:29AM -0500, Lyle Johnson wrote: > On 4/18/07, Mauricio Fernandez wrote: > > > AFAIK the code in the svn repos will not work with 1.9, but moriq (Kazuhiro > > Yoshida) has created a branch that runs on 1.9[1], take a look at > > > > http://collaboa.moriq.com/rubygems-for-ruby-1-9/repository/changesets > > Do you know how can I check out this branch? I've tried a few things > along the lines of: > > svn checkout \ > http://collaboa.moriq.com/rubygems-for-ruby-1-9/repository/trunk \ > rubygems-for-ruby-1.9 > > but haven't hit on the correct URL yet (and I can't find any pointers > on the site itself). I found this address on the blog http://dev.moriq.com/svn/local/rubygems/trunk However, it's not accessible anymore, unlike the Rails and rake branches http://dev.moriq.com/svn/local/rake/trunk http://dev.moriq.com/svn/local/rails/trunk I will try to see if it can be made available again. -- Mauricio Fernandez - http://eigenclass.org - singular Ruby ** Latest postings ** simplefold: better vim folding (Ruby, Objective Caml, Perl, PHP, Java) http://eigenclass.org/hiki/simplefold evil.rb wants love http://eigenclass.org/hiki/evil.rb-wants-love From mfp at acm.org Wed Apr 18 12:00:30 2007 From: mfp at acm.org (Mauricio Fernandez) Date: Wed, 18 Apr 2007 18:00:30 +0200 Subject: [Rubygems-developers] RubyGems 0.9.2 on Ruby 1.9? In-Reply-To: <20070418153751.GL17734@tux-chan> References: <20070418135945.GK17734@tux-chan> <20070418153751.GL17734@tux-chan> Message-ID: <20070418160030.GM17734@tux-chan> Mauricio Fernandez??? On Wed, Apr 18, 2007 at 05:37:51PM +0200, Mauricio Fernandez wrote: > On Wed, Apr 18, 2007 at 09:17:29AM -0500, Lyle Johnson wrote: > > On 4/18/07, Mauricio Fernandez wrote: > > > > > AFAIK the code in the svn repos will not work with 1.9, but moriq (Kazuhiro > > > Yoshida) has created a branch that runs on 1.9[1], take a look at > > > > > > http://collaboa.moriq.com/rubygems-for-ruby-1-9/repository/changesets > > > > Do you know how can I check out this branch? I've tried a few things > > along the lines of: > > > > svn checkout \ > > http://collaboa.moriq.com/rubygems-for-ruby-1-9/repository/trunk \ > > rubygems-for-ruby-1.9 > > > > but haven't hit on the correct URL yet (and I can't find any pointers > > on the site itself). > > I found this address on the blog > http://dev.moriq.com/svn/local/rubygems/trunk > However, it's not accessible anymore, unlike the Rails and rake branches > http://dev.moriq.com/svn/local/rake/trunk > http://dev.moriq.com/svn/local/rails/trunk > I will try to see if it can be made available again. ???????????????????????????????????????? ?????????URL?????????? -> http://dev.moriq.com/svn/local/rubygems/trunk? ??????????? -- Mauricio Fernandez - http://eigenclass.org - singular Ruby ** Latest postings ** simplefold: better vim folding (Ruby, Objective Caml, Perl, PHP, Java) http://eigenclass.org/hiki/simplefold evil.rb wants love http://eigenclass.org/hiki/evil.rb-wants-love From drbrain at segment7.net Wed Apr 18 15:12:49 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 18 Apr 2007 12:12:49 -0700 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: <4625A60D.4090109@sun.com> References: <462595E2.8070008@sun.com> <4625A60D.4090109@sun.com> Message-ID: <97FCF960-9E49-48A8-95BB-DAFB31A89584@segment7.net> On Apr 17, 2007, at 22:01, Charles Oliver Nutter wrote: > Jim Weirich wrote: >> On 4/17/07, Charles Oliver Nutter wrote: >>> Is there a way in RubyGems today to specify that one of a number of >>> modules would be considered equivalent, and to load whichever is >>> actually present? So that during install, options could be >>> presented for >>> multiple named gems that provide the same functionality? >> >> Would it work to just make platform dependent variants of the gems in >> question? Currently, RubyGems will make you manually choose the right >> platform (future versions will autoselect the correct platform for >> you). > > I think it's more than just choosing the right platform...it's an > issue > that if every gem out there depends on "mongrel" there's not a > thing we > can do to force them to install and run with "jmongrel", even if > the two > are nearly identical. No, they'd install the java platformed mongrel, much like there's a mswin and ruby platformed mysql gem. Nothing changes in code anywhere, people running jruby instead install java gems. From jos at catnook.com Wed Apr 18 18:05:49 2007 From: jos at catnook.com (Jos Backus) Date: Wed, 18 Apr 2007 15:05:49 -0700 Subject: [Rubygems-developers] Pointing gem clients to local server(s) ONLY Message-ID: <20070418220549.GA25303@lizzy.catnook.local> Hi, I'm trying to solve the problem of not being able to easily automate which version of a particular gem will be installed by controlling the list of gems available to the gem client. As an example, `gem install mysql' offers a dialog because http://gems.rubyforge.org lists multiple available versions of this gem. Additionally, `gem list -r --source http://myhost:8808' consults more than just http://myhost:8808, it also consults http://gems.rubyforge.org which I don't want it to. I.e. if `--source' is specified, its values should override the values produced by `gem sources'. Does that make sense? This post suggests patching and rebuilding the rubygems sources: http://rambleon.org/2007/02/13/creating-your-own-gem-server/ Is there a better way of doing this, possibly planned for 0.9.3? Thanks, -- Jos Backus jos at catnook.com From rmichael-ruby at edgeofthenet.org Wed Apr 18 19:28:02 2007 From: rmichael-ruby at edgeofthenet.org (Richard Michael) Date: Wed, 18 Apr 2007 19:28:02 -0400 Subject: [Rubygems-developers] Userdir install and GEM_HOME when doing: gem update --system Message-ID: <20070418232802.GC23529@server> Hello list, Where do I file bug reports and/or ask for support for rubygems? I only found this -developers list on rubyforge. Is there a -users list somewhere? .. I have rubygems installed, as per the docs, in a user directory and have my environment as: GEM_HOME=/home/testuser/ruby/lib/ruby/gems/1.8 RUBYLIB=/home/testuser/ruby/lib/ruby:/home/rmichael/ruby/lib/ruby/site_ruby/1.8 RUBY_PREFIX=/home/testuser/ruby "gem update --system" doesn't appear to honour GEM_HOME, and it wants to install into /usr/bin/ (e.g. /usr/bin/gemwhich), as seen below. What's more, "gem update" reports "Rubygems system software updated", although it hasn't been, as it errored out during install. Aside, what's the best way to fix this? At the moment, I switch to the downloaded rubygem update (e.g. GEM_HOME/gems/rubygems-update-0.9.2/), then run the install sequence again: ruby setup.rb config --prefix=$GEM_HOME ruby setup.rb setup ruby setup.rb install Regards, Richard [testuser at hostname ~]$ gem update --system Updating RubyGems... Bulk updating Gem source index for: http://gems.rubyforge.org Attempting remote update of rubygems-update Successfully installed rubygems-update-0.9.2 Updating version of RubyGems to 0.9.2 Installing RubyGems 0.9.2 ---> bin <--- bin ---> lib ---> lib/rbconfig <--- lib/rbconfig ---> lib/rubygems <--- lib/rubygems <--- lib ---> bin <--- bin ---> lib ---> lib/rbconfig <--- lib/rbconfig ---> lib/rubygems <--- lib/rubygems <--- lib rm -f InstalledFiles ---> bin mkdir -p /usr/bin/ install gemwhich /usr/bin/ setup.rb:515:in `initialize': Permission denied - /usr/bin/gemwhich (Errno::EACCES) from setup.rb:515:in `open' from setup.rb:515:in `install' from setup.rb:1200:in `install_files' from setup.rb:1199:in `each' from setup.rb:1199:in `install_files' from setup.rb:1179:in `install_dir_bin' from setup.rb:1328:in `__send__' from setup.rb:1328:in `traverse' ... 6 levels... from setup.rb:894:in `exec_install' from setup.rb:712:in `invoke' from setup.rb:681:in `invoke' from setup.rb:1359 RubyGems system software updated [testuser at hostname ~] From charles.nutter at sun.com Wed Apr 18 23:43:03 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Wed, 18 Apr 2007 22:43:03 -0500 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: <97FCF960-9E49-48A8-95BB-DAFB31A89584@segment7.net> References: <462595E2.8070008@sun.com> <4625A60D.4090109@sun.com> <97FCF960-9E49-48A8-95BB-DAFB31A89584@segment7.net> Message-ID: <4626E547.1080807@sun.com> Eric Hodel wrote: > On Apr 17, 2007, at 22:01, Charles Oliver Nutter wrote: >> Jim Weirich wrote: >>> On 4/17/07, Charles Oliver Nutter wrote: >>>> Is there a way in RubyGems today to specify that one of a number of >>>> modules would be considered equivalent, and to load whichever is >>>> actually present? So that during install, options could be >>>> presented for >>>> multiple named gems that provide the same functionality? >>> Would it work to just make platform dependent variants of the gems in >>> question? Currently, RubyGems will make you manually choose the right >>> platform (future versions will autoselect the correct platform for >>> you). >> I think it's more than just choosing the right platform...it's an >> issue >> that if every gem out there depends on "mongrel" there's not a >> thing we >> can do to force them to install and run with "jmongrel", even if >> the two >> are nearly identical. > > No, they'd install the java platformed mongrel, much like there's a > mswin and ruby platformed mysql gem. Nothing changes in code > anywhere, people running jruby instead install java gems. Well, but that's the point...we have to have a java-platformed mongrel, which means that Zed, who 'owns' the "mongrel" gem name, would have to be responsible for publishing a Java platform gem. As much as we'd like to just give our working Java code to gem owners, it seems unreasonable to expect that they'll all do this publishing for us, and it seems inappropriate for us to publish our own gem called "mongrel" that only supports Java. It's also not an all-or-nothing thing...most gems don't have native code and will work fine in JRuby, so splitting off a separate repository just for those gems that do have native code seems like a lot of hassle. - Charlie From public at bagotricks.com Thu Apr 19 00:19:24 2007 From: public at bagotricks.com (Thomas Palmer) Date: Wed, 18 Apr 2007 21:19:24 -0700 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: <97FCF960-9E49-48A8-95BB-DAFB31A89584@segment7.net> References: <462595E2.8070008@sun.com> <4625A60D.4090109@sun.com> <97FCF960-9E49-48A8-95BB-DAFB31A89584@segment7.net> Message-ID: <4626EDCC.3050302@bagotricks.com> Eric Hodel wrote: > No, they'd install the java platformed mongrel, much like there's a > mswin and ruby platformed mysql gem. Nothing changes in code > anywhere, people running jruby instead install java gems. > > This still leaves the issues I mentioned: 1. "gem install" doesn't default to the current platform (in my tests), so people are forced to choose instead of letting install just work. 2. I can't install and have active in the same local repo multiple platforms of the same gem (i.e., different ones active for different platforms). 3. People getting confused when saying "Hey, this library doesn't work according to docs!" and mistaking the responsible party. Maybe that can be somewhat mitigated by clarifying in the author and other fields of the platform-specific gem. Any official thoughts on these, especially items 1 and 2? (Those are more of the technical side. Item 3 is more of a social/communication issue.) Thanks much, Tom From public at bagotricks.com Thu Apr 19 00:26:59 2007 From: public at bagotricks.com (Thomas Palmer) Date: Wed, 18 Apr 2007 21:26:59 -0700 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: <4626E547.1080807@sun.com> References: <462595E2.8070008@sun.com> <4625A60D.4090109@sun.com> <97FCF960-9E49-48A8-95BB-DAFB31A89584@segment7.net> <4626E547.1080807@sun.com> Message-ID: <4626EF93.2060403@bagotricks.com> Charles Oliver Nutter wrote: > Well, but that's the point...we have to have a java-platformed mongrel, > which means that Zed, who 'owns' the "mongrel" gem name, would have to > be responsible for publishing a Java platform gem. As much as we'd like > to just give our working Java code to gem owners, it seems unreasonable > to expect that they'll all do this publishing for us, and it seems > inappropriate for us to publish our own gem called "mongrel" that only > supports Java. > > > On this topic, if you specify a gem platform, you get a gem named like so: --.gem And it can coexist in a remote (or even local repo) with platformless versions or versions for other platforms. When installing, you get a menu of choices. Probably could just drop in the "-java" version into RubyForge's repo, but it risks social strain perhaps. And it has the other drawbacks I mentioned. And I bet you could get complaints on the "please choose your gem" (or however that's worded) menu for gems that previously didn't have the pain. Maybe that "provides" idea from darix could work. So install would be different but local use would be fine. (Note that I'd still like to see different local gems defaulting to be active for different local rubies, even multiple installs of normal ruby.) - Tom From charles.nutter at sun.com Thu Apr 19 03:09:25 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Thu, 19 Apr 2007 02:09:25 -0500 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: <4626EF93.2060403@bagotricks.com> References: <462595E2.8070008@sun.com> <4625A60D.4090109@sun.com> <97FCF960-9E49-48A8-95BB-DAFB31A89584@segment7.net> <4626E547.1080807@sun.com> <4626EF93.2060403@bagotricks.com> Message-ID: <462715A5.2060701@sun.com> Thomas Palmer wrote: > On this topic, if you specify a gem platform, you get a gem named like so: > > --.gem > > And it can coexist in a remote (or even local repo) with platformless > versions or versions for other platforms. When installing, you get a > menu of choices. Probably could just drop in the "-java" version into > RubyForge's repo, but it risks social strain perhaps. That social strain is exactly what I want to avoid. I think you're right, I could just publish a mongrel-#.#-java.gem file to RubyForge and it would work, but that seems like a good way to start pissing people off. > And it has the other drawbacks I mentioned. And I bet you could get > complaints on the "please choose your gem" (or however that's worded) > menu for gems that previously didn't have the pain. Though in most cases, the gems that would have a choice with Java added will already have a choice now (since they'll depend on native code...if they didn't, we wouldn't need a Java version). I don't think this is likely to be as big an issue, but obviously if RubyGems could just pick the right platform it would be a complete non-issue (i.e. if there's a choice of platform and "java" is one of them, that's guaranteed to be right for us...and wrong for anyone not on JRuby). > Maybe that "provides" idea from darix could work. So install would be > different but local use would be fine. (Note that I'd still like to see > different local gems defaulting to be active for different local rubies, > even multiple installs of normal ruby.) This is basically what I had in mind, but I've never tried to design or specify a package management system, so it's all pretty cloudy. Whatever works for other systems would probably be applicable here. All I know is that I want to be able to provide drop-in-replacement Java versions of C-based gems with as little strain on the original authors as possible. - Charlie From jim.weirich at gmail.com Thu Apr 19 07:10:50 2007 From: jim.weirich at gmail.com (Jim Weirich) Date: Thu, 19 Apr 2007 07:10:50 -0400 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: <4626EDCC.3050302@bagotricks.com> References: <462595E2.8070008@sun.com> <4625A60D.4090109@sun.com> <97FCF960-9E49-48A8-95BB-DAFB31A89584@segment7.net> <4626EDCC.3050302@bagotricks.com> Message-ID: On 4/19/07, Thomas Palmer wrote: > 1. "gem install" doesn't default to the current platform (in my tests), > so people are forced to choose instead of letting install just work. yes, but this is easily solvable ... its on the todo list for the gems team. This issue will just push it to the front of the list. > 2. I can't install and have active in the same local repo multiple > platforms of the same gem (i.e., different ones active for different > platforms). Really? I think the repository structure should support this. We might need some extra logic in the activate code to make sure we get the right platform. > 3. People getting confused when saying "Hey, this library doesn't work > according to docs!" and mistaking the responsible party. Maybe that can > be somewhat mitigated by clarifying in the author and other fields of > the platform-specific gem. Yes, I don't know what to do about that. I think that if you were to offer a java based version of any current gem, you would want to work with the original author anyways ...to coordinate releases and keep compatibility, etc. Under today's RubyForge structure, you would have to publish the gem from the same RubyForge project, but that doesn't mean you have to share the same SVN repository. -- -- Jim Weirich jim at weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) From drbrain at segment7.net Thu Apr 19 12:17:15 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 19 Apr 2007 09:17:15 -0700 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: <4626E547.1080807@sun.com> References: <462595E2.8070008@sun.com> <4625A60D.4090109@sun.com> <97FCF960-9E49-48A8-95BB-DAFB31A89584@segment7.net> <4626E547.1080807@sun.com> Message-ID: <1D49CC1B-6F64-4682-B17C-F0A4F73A7C6A@segment7.net> On Apr 18, 2007, at 20:43, Charles Oliver Nutter wrote: > Eric Hodel wrote: >> On Apr 17, 2007, at 22:01, Charles Oliver Nutter wrote: >>> I think it's more than just choosing the right platform...it's an >>> issue that if every gem out there depends on "mongrel" there's not a >>> thing we can do to force them to install and run with "jmongrel", >>> even if >>> the two are nearly identical. >> >> No, they'd install the java platformed mongrel, much like there's a >> mswin and ruby platformed mysql gem. Nothing changes in code >> anywhere, people running jruby instead install java gems. > > Well, but that's the point...we have to have a java-platformed > mongrel, > which means that Zed, who 'owns' the "mongrel" gem name, would have to > be responsible for publishing a Java platform gem. So we're really just looking for a technical solution to a social problem. Has the author of the java mongrel port asked Zed to be a member of the mongrel project so the port can be distributed from the same project, and the code be kept in one place for maintainability? Has Zed refused? If both of those answers are yes, then *maybe* we should look into writing some code. (Really, some gentle social pressure should be applied first, then, still, *maybe* we should look into writing some code.) Otherwise, no. From drbrain at segment7.net Thu Apr 19 12:21:06 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 19 Apr 2007 09:21:06 -0700 Subject: [Rubygems-developers] Userdir install and GEM_HOME when doing: gem update --system In-Reply-To: <20070418232802.GC23529@server> References: <20070418232802.GC23529@server> Message-ID: <8A321E8B-F4C2-4898-A717-0B13CC1662B1@segment7.net> On Apr 18, 2007, at 16:28, Richard Michael wrote: > Where do I file bug reports On the rubygems project on rubyforge. > and/or ask for support for rubygems? Here. > I only found this -developers list on rubyforge. Is there a -users > list > somewhere? No. > I have rubygems installed, as per the docs, in a user directory and > have my environment as: > > GEM_HOME=/home/testuser/ruby/lib/ruby/gems/1.8 > RUBYLIB=/home/testuser/ruby/lib/ruby:/home/rmichael/ruby/lib/ruby/ > site_ruby/1.8 > RUBY_PREFIX=/home/testuser/ruby > > "gem update --system" doesn't appear to honour GEM_HOME, and it > wants to > install into /usr/bin/ (e.g. /usr/bin/gemwhich), as seen below. > > What's more, "gem update" reports "Rubygems system software updated", > although it hasn't been, as it errored out during install. > > Aside, what's the best way to fix this? At the moment, I switch to > the > downloaded rubygem update (e.g. GEM_HOME/gems/rubygems-update-0.9.2/), > then run the install sequence again: > > ruby setup.rb config --prefix=$GEM_HOME > ruby setup.rb setup > ruby setup.rb install Please check to see if a bug has been filed on this, and if it hasn't, please file one. From drbrain at segment7.net Thu Apr 19 12:23:43 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 19 Apr 2007 09:23:43 -0700 Subject: [Rubygems-developers] Pointing gem clients to local server(s) ONLY In-Reply-To: <20070418220549.GA25303@lizzy.catnook.local> References: <20070418220549.GA25303@lizzy.catnook.local> Message-ID: <69B15E55-9741-4A04-B091-2A48BEBD56CE@segment7.net> On Apr 18, 2007, at 15:05, Jos Backus wrote: > I'm trying to solve the problem of not being able to easily > automate which > version of a particular gem will be installed by controlling the > list of gems > available to the gem client. As an example, `gem install mysql' > offers a > dialog because http://gems.rubyforge.org lists multiple available > versions of > this gem. > > Additionally, `gem list -r --source http://myhost:8808' consults > more than > just http://myhost:8808, it also consults http://gems.rubyforge.org > which I > don't want it to. I.e. if `--source' is specified, its values > should override > the values produced by `gem sources'. Does that make sense? Please file a bug. > This post suggests patching and rebuilding the rubygems sources: > > http://rambleon.org/2007/02/13/creating-your-own-gem-server/ This link is gone. > Is there a better way of doing this, possibly planned for 0.9.3? Yes, see the bugs list. You may be able to work around this using the sources subcommand to remove rubyforge's repository. From jos at catnook.com Thu Apr 19 16:06:09 2007 From: jos at catnook.com (Jos Backus) Date: Thu, 19 Apr 2007 13:06:09 -0700 Subject: [Rubygems-developers] Pointing gem clients to local server(s) ONLY In-Reply-To: <69B15E55-9741-4A04-B091-2A48BEBD56CE@segment7.net> References: <20070418220549.GA25303@lizzy.catnook.local> <69B15E55-9741-4A04-B091-2A48BEBD56CE@segment7.net> Message-ID: <20070419200609.GA17552@lizzy.catnook.local> On Thu, Apr 19, 2007 at 09:23:43AM -0700, Eric Hodel wrote: > On Apr 18, 2007, at 15:05, Jos Backus wrote: > > Additionally, `gem list -r --source http://myhost:8808' consults more than > > just http://myhost:8808, it also consults http://gems.rubyforge.org which I > > don't want it to. I.e. if `--source' is specified, its values should > > override > > the values produced by `gem sources'. Does that make sense? > > Please file a bug. Filed as bug 10236. > > This post suggests patching and rebuilding the rubygems sources: > > > > http://rambleon.org/2007/02/13/creating-your-own-gem-server/ > > This link is gone. That's because Jim responded to the entry and the author updated it. Please try http://rambleon.org/2007/04/19/creating-your-own-gem-server/ > > Is there a better way of doing this, possibly planned for 0.9.3? > > Yes, see the bugs list. > > You may be able to work around this using the sources subcommand to remove > rubyforge's repository. That doesn't work either. Filed as bug 10235. Thanks Eric. -- Jos Backus jos at catnook.com From public at bagotricks.com Thu Apr 19 21:32:46 2007 From: public at bagotricks.com (Thomas Palmer) Date: Thu, 19 Apr 2007 18:32:46 -0700 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: References: <462595E2.8070008@sun.com> <4625A60D.4090109@sun.com> <97FCF960-9E49-48A8-95BB-DAFB31A89584@segment7.net> <4626EDCC.3050302@bagotricks.com> Message-ID: <4628183E.90807@bagotricks.com> Thanks much for the detailed replies to these issues (and especially if some of the mentioned changes get made). I'll see if I can provide a more detailed report on item #2 that I mentioned. - Tom Jim Weirich wrote: > On 4/19/07, Thomas Palmer wrote: > >> 1. "gem install" doesn't default to the current platform (in my tests), >> so people are forced to choose instead of letting install just work. >> > > yes, but this is easily solvable ... its on the todo list for the gems > team. This issue will just push it to the front of the list. > > >> 2. I can't install and have active in the same local repo multiple >> platforms of the same gem (i.e., different ones active for different >> platforms). >> > > Really? I think the repository structure should support this. We > might need some extra logic in the activate code to make sure we get > the right platform. > > >> 3. People getting confused when saying "Hey, this library doesn't work >> according to docs!" and mistaking the responsible party. Maybe that can >> be somewhat mitigated by clarifying in the author and other fields of >> the platform-specific gem. >> > > Yes, I don't know what to do about that. I think that if you were to > offer a java based version of any current gem, you would want to work > with the original author anyways ...to coordinate releases and keep > compatibility, etc. Under today's RubyForge structure, you would have > to publish the gem from the same RubyForge project, but that doesn't > mean you have to share the same SVN repository. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20070419/1f8daae7/attachment.html From charles.nutter at sun.com Thu Apr 19 21:34:51 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Thu, 19 Apr 2007 20:34:51 -0500 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: <1D49CC1B-6F64-4682-B17C-F0A4F73A7C6A@segment7.net> References: <462595E2.8070008@sun.com> <4625A60D.4090109@sun.com> <97FCF960-9E49-48A8-95BB-DAFB31A89584@segment7.net> <4626E547.1080807@sun.com> <1D49CC1B-6F64-4682-B17C-F0A4F73A7C6A@segment7.net> Message-ID: <462818BB.9090501@sun.com> Eric Hodel wrote: > On Apr 18, 2007, at 20:43, Charles Oliver Nutter wrote: >> Eric Hodel wrote: >>> On Apr 17, 2007, at 22:01, Charles Oliver Nutter wrote: >>>> I think it's more than just choosing the right platform...it's an >>>> issue that if every gem out there depends on "mongrel" there's not a >>>> thing we can do to force them to install and run with "jmongrel", >>>> even if >>>> the two are nearly identical. >>> No, they'd install the java platformed mongrel, much like there's a >>> mswin and ruby platformed mysql gem. Nothing changes in code >>> anywhere, people running jruby instead install java gems. >> Well, but that's the point...we have to have a java-platformed >> mongrel, >> which means that Zed, who 'owns' the "mongrel" gem name, would have to >> be responsible for publishing a Java platform gem. > > So we're really just looking for a technical solution to a social > problem. Not exactly. The problem is that there's no way to provide a jmongrel that can be installed wherever mongrel would be installed, even if they're compatible. If gem X depends on mongrel, there's no way to install it without installing mongrel, even if your platform would need jmongrel. You can force it to install and skip all dependencies, but that cuts out modules that might otherwise install just fine. Other package systems handle this by making sure nobody "owns" the name for a given package, typically tying dependencies to generic top-level names like "perl" or "java". If you depend on "java" it's provided by any number of packages like GCJ, Sun or IBM JDKs, and so on. There's no equivalent with gems, since dependencies are not specified to a given "feature", they're specified to a single specific implementation. There's no flexibility for providing that feature with a different implementation, unless you can convince the owner of the primary implementation to release your code for you. Would it make sense if alternative implementations of "java" had to ask Sun to release their packages for them? > Has the author of the java mongrel port asked Zed to be a member of > the mongrel project so the port can be distributed from the same > project, and the code be kept in one place for maintainability? > > Has Zed refused? Zed has agreed, and Zed is interested in releasing the code, when he gets time and once we've shown how to build it and once we arrange to keep it updated on his end and once we figure out testing and release procedures from version to version for code he doesn't maintain... However to have to expect each and every author of a native module to do all this is silly. They shouldn't have to do it, and we shouldn't expect them to do it. But if jmongrel or anything else is functionally equivalent to mongrel under JRuby (and in truth, the only way someone running JRuby can run mongrel), there should be a simple way to fit jmongrel into the family without having to hassle Zed or anyone else. - Charlie From jim.weirich at gmail.com Thu Apr 19 22:08:46 2007 From: jim.weirich at gmail.com (Jim Weirich) Date: Thu, 19 Apr 2007 22:08:46 -0400 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: <462818BB.9090501@sun.com> References: <462595E2.8070008@sun.com> <4625A60D.4090109@sun.com> <97FCF960-9E49-48A8-95BB-DAFB31A89584@segment7.net> <4626E547.1080807@sun.com> <1D49CC1B-6F64-4682-B17C-F0A4F73A7C6A@segment7.net> <462818BB.9090501@sun.com> Message-ID: On 4/19/07, Charles Oliver Nutter wrote: > Eric Hodel wrote: > > On Apr 18, 2007, at 20:43, Charles Oliver Nutter wrote: > >> Eric Hodel wrote: > >>> On Apr 17, 2007, at 22:01, Charles Oliver Nutter wrote: > >> which means that Zed, who 'owns' the "mongrel" gem name, would have to > >> be responsible for publishing a Java platform gem. Actually, no. See below. > However to have to expect each and every author of a native module to do > all this is silly. They shouldn't have to do it, and we shouldn't expect > them to do it. But if jmongrel or anything else is functionally > equivalent to mongrel under JRuby (and in truth, the only way someone > running JRuby can run mongrel), there should be a simple way to fit > jmongrel into the family without having to hassle Zed or anyone else. Zed would not have to be "responsible" for releasing a java platform mongrel gem. Someone else could do all the work and even handle the release. The only coordination that would be required is that for a given version number, the C platform and the Java platform gems have compatible APIs. The two platforms would require some level of compatiblity anyways, otherwise plain ruby software would not be able to run on the other. The reason for the version alignment is so that if my software requires version 1.2 of mongrel, it means the same thing in both MRI and JRuby land. On version alignment, the two platforms wouldn't even to be *exactly* aligned. Generally (if used properly in the Gem world), only the first two numbers of a version denote features. The third (and beyond third) number in the version generally denotes build revisions. So, if mongrel-C and mongrel-JRuby keep feature aligned on the first two numbers in a version, i suspect that would be adequate. The only other (minor) problem I see is that currently RubyForge requires that a Gem come from a single RubyForge project. I suspect we can convince the RubyForge guys to allow different platform gems to come from different projects. -- -- Jim Weirich jim at weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas) From charles.nutter at sun.com Thu Apr 19 23:49:18 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Thu, 19 Apr 2007 22:49:18 -0500 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: References: <462595E2.8070008@sun.com> <4625A60D.4090109@sun.com> <97FCF960-9E49-48A8-95BB-DAFB31A89584@segment7.net> <4626E547.1080807@sun.com> <1D49CC1B-6F64-4682-B17C-F0A4F73A7C6A@segment7.net> <462818BB.9090501@sun.com> Message-ID: <4628383E.4010509@sun.com> Jim Weirich wrote: > Zed would not have to be "responsible" for releasing a java platform > mongrel gem. Someone else could do all the work and even handle the > release. The only coordination that would be required is that for a > given version number, the C platform and the Java platform gems have > compatible APIs. So is the right answer that if we made mongrel gems for the Java version and just handed them over to Zed to publish through RubyForge, that would be the right way to go forward? That probably works well enough, but perhaps there's issues of who to come to with problems on the Java version (people will go to the project they got it from) and similar questions. Maybe that's not a big deal. > The two platforms would require some level of > compatiblity anyways, otherwise plain ruby software would not be able > to run on the other. The reason for the version alignment is so that > if my software requires version 1.2 of mongrel, it means the same > thing in both MRI and JRuby land. This is all cool...indeed the goal of these ports is to provide a gem that looks and feels in JRuby just like the C version of the gem looks and feels in MRI. And in cases like Mongrel and Hpricot, that's exactly what we have. > On version alignment, the two platforms wouldn't even to be *exactly* > aligned. Generally (if used properly in the Gem world), only the > first two numbers of a version denote features. The third (and beyond > third) number in the version generally denotes build revisions. So, > if mongrel-C and mongrel-JRuby keep feature aligned on the first two > numbers in a version, i suspect that would be adequate. In this case, the only piece that's even different is the HTTP request parser, which is generated from Ragel source for both the C version and the Java version, so tracking features almost happens automatically. The hard part is making sure it's built and appropriate for current JRuby (soon to be 1.0ish) and the publishing issue. > The only other (minor) problem I see is that currently RubyForge > requires that a Gem come from a single RubyForge project. I suspect > we can convince the RubyForge guys to allow different platform gems to > come from different projects. That would actually be enough if you ask me...but only if it's considered "ok" within the gem-publishing world. I've seen others get very upset in a few cases where a gem was accidentally published that had the same name as another, causing some trouble and confusion. It would be trivial for us to create our own gem and handle publishing it to our own jmongrel project, if it could fulfill the requirement of "mongrel" other gems specify. Perhaps there should be something in the list of gems specifying that this is "mongrel (java, "jmongrel")" so people know if they're getting a gem from a potentially different project? - Charlie From drbrain at segment7.net Fri Apr 20 12:21:05 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 20 Apr 2007 09:21:05 -0700 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: <4628383E.4010509@sun.com> References: <462595E2.8070008@sun.com> <4625A60D.4090109@sun.com> <97FCF960-9E49-48A8-95BB-DAFB31A89584@segment7.net> <4626E547.1080807@sun.com> <1D49CC1B-6F64-4682-B17C-F0A4F73A7C6A@segment7.net> <462818BB.9090501@sun.com> <4628383E.4010509@sun.com> Message-ID: On Apr 19, 2007, at 20:49, Charles Oliver Nutter wrote: > Jim Weirich wrote: >> Zed would not have to be "responsible" for releasing a java platform >> mongrel gem. Someone else could do all the work and even handle the >> release. The only coordination that would be required is that for a >> given version number, the C platform and the Java platform gems have >> compatible APIs. > > So is the right answer that if we made mongrel gems for the Java > version > and just handed them over to Zed to publish through RubyForge, that > would be the right way to go forward? That probably works well enough, > but perhaps there's issues of who to come to with problems on the Java > version (people will go to the project they got it from) and similar > questions. Maybe that's not a big deal. You don't even need to wait for Zed. If you're on the project you can do the release all by yourself. Both Jim and I have released Rubygems on Rubyforge. The only interaction necessary by Zed is to add the Java maintainer to the project. From charles.nutter at sun.com Fri Apr 20 19:29:58 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Fri, 20 Apr 2007 18:29:58 -0500 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: References: <462595E2.8070008@sun.com> <4625A60D.4090109@sun.com> <97FCF960-9E49-48A8-95BB-DAFB31A89584@segment7.net> <4626E547.1080807@sun.com> <1D49CC1B-6F64-4682-B17C-F0A4F73A7C6A@segment7.net> <462818BB.9090501@sun.com> <4628383E.4010509@sun.com> Message-ID: <46294CF6.2080800@sun.com> Eric Hodel wrote: > On Apr 19, 2007, at 20:49, Charles Oliver Nutter wrote: >> Jim Weirich wrote: >>> Zed would not have to be "responsible" for releasing a java platform >>> mongrel gem. Someone else could do all the work and even handle the >>> release. The only coordination that would be required is that for a >>> given version number, the C platform and the Java platform gems have >>> compatible APIs. >> So is the right answer that if we made mongrel gems for the Java >> version >> and just handed them over to Zed to publish through RubyForge, that >> would be the right way to go forward? That probably works well enough, >> but perhaps there's issues of who to come to with problems on the Java >> version (people will go to the project they got it from) and similar >> questions. Maybe that's not a big deal. > > You don't even need to wait for Zed. If you're on the project you > can do the release all by yourself. Both Jim and I have released > Rubygems on Rubyforge. The only interaction necessary by Zed is to > add the Java maintainer to the project. So for every such case, we should join the project? - Charlie From jim at weirichhouse.org Fri Apr 20 19:41:23 2007 From: jim at weirichhouse.org (Jim Weirich) Date: Fri, 20 Apr 2007 19:41:23 -0400 Subject: [Rubygems-developers] Specifying equivalent modules? In-Reply-To: <46294CF6.2080800@sun.com> References: <462595E2.8070008@sun.com> <4625A60D.4090109@sun.com> <97FCF960-9E49-48A8-95BB-DAFB31A89584@segment7.net> <4626E547.1080807@sun.com> <1D49CC1B-6F64-4682-B17C-F0A4F73A7C6A@segment7.net> <462818BB.9090501@sun.com> <4628383E.4010509@sun.com> <46294CF6.2080800@sun.com> Message-ID: <46294FA3.6090400@weirichhouse.org> Charles Oliver Nutter wrote: > So for every such case, we should join the project? I think there are several scenarios, each project should find its own balance. (1) Both C and Java developers join the same project. The both parties coordinate their releases, but each party handles the mechanics of their own releases. (2) The Java developers send their gem (and announcements, news releases, changelogs, etc) to the primary developer. In this case the primary developer does the actual release. More work for the primary developer, but also more control. (3) The Java and C developer is the same guy who releases all platform gems at the same time. (4) The Java code is released from a different RubyForge project, with no interaction with the primary developer (beyond version conformance). In this scenario, I suspect we will have to get help from the RubyForge folk to make sure that the same base gem with different platform can be released from different projects (but I don't anticipate trouble there). In the above, I generally phrased it with the C source as the primary project and the Java version being the derived version, but I can easily imagine projects where the roles are reversed, or even co-equal. -- -- Jim Weirich jim at weirichhouse.org http://onestepback.org -- In theory, practice and theory are the same. -- In practice, they are different. From jim at weirichhouse.org Mon Apr 23 22:14:56 2007 From: jim at weirichhouse.org (Jim Weirich) Date: Mon, 23 Apr 2007 22:14:56 -0400 Subject: [Rubygems-developers] Platform Specification and Auto-selecting the Platform Message-ID: <462D6820.6070104@weirichhouse.org> Warning: Long Message Follows ... The recent thread on specifying equivalent gems brought out the fact that RubyGems does not provide a good interface for selecting from multiple platform gems. Chad and I had a discussion earlier this year about handling that situation better. One of the things we need to understand is exactly what kind of platforms we need to deal with and that lead to the Tattle project (http://www.chadfowler.com/2007/1/8/tattle-the-ruby-census). I haven't seen the results of tattle yet (perhaps Chad would like to share the gathered data), but I have been thinking about a framework for platforms. Let me lay that out now and get feedback, and we can work the details of exactly what platforms we need into the framework when we have the tattle data. The current situation is that we have essentially two types of platforms, Ruby and Win32 right now (is there anything else?). Soon we will be getting gems with a Java / JRuby platform. I'm thinking its time to organize that. My proposal is to have 3 types of platforms: (1) Pure Ruby Platform. Gems in this category can be run using just a Ruby runtime (either MRI, Yarv, or JRuby). A good number of gems will fall into this category. Pure ruby gems will be designated with "ruby" (no designation defaults to a pure ruby gem). (2) Source Gems. Source gems are gems that come with source code that needs to be built (compiled, links, etc) in order to be installed. Source code gems will be designated either "C" or "Java" depending on the language of the source code. Other languages could be supported in the future, but this will do for now. (3) Binary Gems. Binary gems have the compiled object code packaged in the gem. During installation, all you have to do copy the libraries (or Jars) to the right location. No compile toolset is needed. Binary gems will be designed hierarchically as follows: (a) Hardwore architecture (e.g. x86, ppc, sparc, jvm). (b) OS (e.g. mswin, linux, macos, bsd, aix) (c) Optional OS variant (xp, vista, redhat, ubuntu) (d) Optional OS revision. So, the binary platform designation for the computer I'm writing this on might be: x86-macos-10.4.9. The hardware platform for my mail server would be x86-linux-debian-2.4.24. My parallels virtual machine might be x86-mswin-xp (I have no idea what version of XP I'm running there, but you get the idea). If I were running JRuby, the binary platform would be simply "jvm-1.4.2". I'm skipping the question of how we can access all this information uniformly across all the platforms. Put that down as your homework assignment. Now, the platform designation for a gem indicates what hareware/os it can run on. So mygem-1.0_jvm-1.4 will run on any Java platform with version 1.4 or better. mygem-1.0_x86-macos-10 will run on any version of MacOS X running on Intel hardware. Since you can produce universal binaries on a mac that run on either Intel or PowerPC, I would suggest that mygem-1.0_uni-macos-10 would be a gem with universal binaries. (Note that proposed naming scheme for gem file names. Will this be a backwards compatibility issue? I don't think so. The gem file name is just so we don't have file names for different platforms that collide. I suspect that RubyGems will get the real platform info from the gemspec itself). So, that's how we designate platforms. How will gems choose a platform (more or less) automatically. Here's the selection process. Gems will know what platform its running on (note to self: do we have to handle cross platform installations?). It just needs to find compatible gems. Here's the process: (1) Determine the latest version of a gem that satisfies the version constraint (exactly as it is handled now). (2) Find all the platforms available for the chosen version. (3) If there is a binary gems that matches the target platform, select the gem that has the longest match (e.g. x86-mswin-xp is a better match than x86-mswin). When matching OS versions, the gem version must be less than or equal to the target version. (4) If there are no matching binary gems, then if the target machine has a compile toolkit available, then select the source gem (either C or Java) that is appropriate. (5) If there are no source gems available, or if the target machine doesn't have a compile environment (i.e. most windows machines), then install the pure ruby platform. The algorithm prefers gems that are more specialized for a particular platform, but falls back with reasonable results. We will probably need a way to override the default platform selection. I would recommend making the override available for only explicitly installed gems (not for gems that are installed automatically because they are dependencies). Does this make sense? What do you think? -- -- Jim Weirich jim at weirichhouse.org http://onestepback.org -- In theory, practice and theory are the same. -- In practice, they are different. From thewoolleyman at gmail.com Mon Apr 23 22:35:52 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 23 Apr 2007 19:35:52 -0700 Subject: [Rubygems-developers] Platform Specification and Auto-selecting the Platform In-Reply-To: <462D6820.6070104@weirichhouse.org> References: <462D6820.6070104@weirichhouse.org> Message-ID: This sounds like a great start for a plan. However, I wonder about this: > I would recommend making the override available for > only explicitly installed gems (not for gems that are installed > automatically because they are dependencies). What is the reason for this? What if a pure-ruby gem has a platform-specific dependency? The user should be able to override that. Or, are you assuming that they will have to be aware of the dependencies, and explicitly pre-install the dependencies with the correct platform first, before the dependent gem is installed? > > Does this make sense? What do you think? Yep. Couple of other questions: - What about legacy gems? Will there be some sort of algorithm to map pre-existing platforms to the new platform spec? - How do you plan to enforce the new platform format? Will there be specific structures and fields in the gem spec to support the hierarchy you proposed? What will prevent people from circumventing this and submitting invalid platforms (if this is possible)? Thanks for tackling this issue, -- Chad W. From jim at weirichhouse.org Tue Apr 24 00:35:15 2007 From: jim at weirichhouse.org (Jim Weirich) Date: Tue, 24 Apr 2007 00:35:15 -0400 Subject: [Rubygems-developers] Platform Specification and Auto-selecting the Platform In-Reply-To: References: <462D6820.6070104@weirichhouse.org> Message-ID: <462D8903.4010608@weirichhouse.org> Chad Woolley wrote: > This sounds like a great start for a plan. However, I wonder about this: > >> I would recommend making the override available for >> only explicitly installed gems (not for gems that are installed >> automatically because they are dependencies). > > What is the reason for this? Complexity of user interface. If I ask RubyGems to install gem a, which depends on gem b, which in turn depends upon gem c, do I really want to be overriding the platform of gem c? Not really. It is much more straight forward to just install gem c directly, overriding the platform, and then install gem a. > What if a pure-ruby gem has a > platform-specific dependency? Gems don't have platform specific dependencies. They depend upon generic gems that may (or may not) have multiple platform specific variants available. If I am installing a pure ruby gem on my Mac that depends on a gem that is only available on a windows platform, the install of the dependent gem will fail, which will in turn fail the install of the original gem. > The user should be able to override > that. Or, are you assuming that they will have to be aware of the > dependencies, and explicitly pre-install the dependencies with the > correct platform first, before the dependent gem is installed? If the defaults don't work, I don't expect anyone to know that before they try. If a default selection on a dependent gem fails, I would expect the user to explicitly install a gem with an override, then continue with the original install. > - What about legacy gems? Will there be some sort of algorithm to map > pre-existing platforms to the new platform spec? I suspect we should be able to scan the existing gems on RubyForge and migrate them more or less automatically. By far the most common types are pure ruby and C source gems, with a smattering of some binary gems. > - How do you plan to enforce the new platform format? Will there be > specific structures and fields in the gem spec to support the > hierarchy you proposed? What will prevent people from circumventing > this and submitting invalid platforms (if this is possible)? I've not given this part too much thought yet. I suspect the range of hardware designations will have to be somewhat controlled, otherwise you will get a variety of synonyms for the same platform (e.g. "windows" vs "win32" vs "mswin", or even "macos" vs "osx" vs "darwin"). I hope the data from the tottle project will drive the specific designations. I'm just trying to put together a framework for categorizing them. > Thanks for tackling this issue, Thanks. It's a long overdue topic. -- -- Jim Weirich jim at weirichhouse.org http://onestepback.org -- In theory, practice and theory are the same. -- In practice, they are different. From public at bagotricks.com Tue Apr 24 00:43:27 2007 From: public at bagotricks.com (Thomas Palmer) Date: Mon, 23 Apr 2007 21:43:27 -0700 Subject: [Rubygems-developers] Platform Specification and Auto-selecting the Platform In-Reply-To: <462D8903.4010608@weirichhouse.org> References: <462D6820.6070104@weirichhouse.org> <462D8903.4010608@weirichhouse.org> Message-ID: <462D8AEF.6030401@bagotricks.com> Jim Weirich wrote: > > - How do you plan to enforce the new platform format? Will there be > > specific structures and fields in the gem spec to support the > > hierarchy you proposed? What will prevent people from circumventing > > this and submitting invalid platforms (if this is possible)? > > I've not given this part too much thought yet. I suspect the > range of hardware designations will have to be somewhat > controlled, otherwise you will get a variety of synonyms for the > same platform (e.g. "windows" vs "win32" vs "mswin", or even > "macos" vs "osx" vs "darwin"). I hope the data from the tottle > project will drive the specific designations. I'm just trying to > put together a framework for categorizing them. > > Thanks much for the plan to work on this. For the platforms, I agree that lots of ways of saying the same thing is bad. But inability for someone to add a new platform designation on their own would also be bad. If the Ruby runtime can state its own platform (which it can - if I understand correctly), then it seems like those are the naming conventions to gravitate around, especially if auto-selection was working. That might be enough gravity to avoid needing to hardcode an acceptable list in RubyGems. - Tom From drbrain at segment7.net Tue Apr 24 17:24:53 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 24 Apr 2007 14:24:53 -0700 Subject: [Rubygems-developers] Platform Specification and Auto-selecting the Platform In-Reply-To: <462D6820.6070104@weirichhouse.org> References: <462D6820.6070104@weirichhouse.org> Message-ID: <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> On Apr 23, 2007, at 19:14, Jim Weirich wrote: > I haven't seen the results of tattle yet (perhaps Chad would like > to share the gathered data) Its downloadable from: http://tattle.rubygarden.org/ From drbrain at segment7.net Tue Apr 24 19:09:05 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 24 Apr 2007 16:09:05 -0700 Subject: [Rubygems-developers] Platform Specification and Auto-selecting the Platform In-Reply-To: <462D6820.6070104@weirichhouse.org> References: <462D6820.6070104@weirichhouse.org> Message-ID: <26069771-B87F-4154-B72D-8E76D5D2C9CD@segment7.net> On Apr 23, 2007, at 19:14, Jim Weirich wrote: > The current situation is that we have essentially two types of > platforms, Ruby and Win32 right now (is there anything else?). Gem::SourceInfoCache.cache_data['http:// gems.rubyforge.org'].source_index.map { |_,g| g.platform }.uniq => ["ruby", "mswin32", "win32-1.8.2-VC7", nil, "i486-linux", "i586- linux", "windows", "i386-mswin32", "i686-darwin8.4.1", "powerpc- darwin7.9.0", "powerpc-darwin", "win32-source", "sparc-solaris2.8- mq5.3", "i386-mswin32-mq5.3", "unix", "win32-1.8.4-VC6", "java", "i686-linux", "i386-linux", "i386-mswin32-mq6"] > Soon we will be getting gems with a Java / JRuby platform. I'm > thinking its time to organize that. > > My proposal is to have 3 types of platforms: > > (1) Pure Ruby Platform. Gems in this category can be run using > just a Ruby runtime (either MRI, Yarv, or JRuby). A good number > of gems will fall into this category. Pure ruby gems will be > designated with "ruby" (no designation defaults to a pure ruby > gem). > > (2) Source Gems. Source gems are gems that come with source code > that needs to be built (compiled, links, etc) in order to be > installed. Source code gems will be designated either "C" or > "Java" depending on the language of the source code. Other > languages could be supported in the future, but this will do for > now. > > (3) Binary Gems. Binary gems have the compiled object code > packaged in the gem. During installation, all you have to do copy > the libraries (or Jars) to the right location. No compile toolset > is needed. > > Binary gems will be designed hierarchically as follows: > > (a) Hardwore architecture (e.g. x86, ppc, sparc, jvm). Don't forget Universal. > (b) OS (e.g. mswin, linux, macos, bsd, aix) > (c) Optional OS variant (xp, vista, redhat, ubuntu) > (d) Optional OS revision. > > So, the binary platform designation for the computer I'm writing > this on might be: x86-macos-10.4.9. The hardware platform for my > mail server would be x86-linux-debian-2.4.24. My parallels > virtual machine might be x86-mswin-xp (I have no idea what > version of XP I'm running there, but you get the idea). If I were > running JRuby, the binary platform would be simply "jvm-1.4.2". > > I'm skipping the question of how we can access all this > information uniformly across all the platforms. Put that down as > your homework assignment. It should all be in Config::CONFIG under the TARGET_* values. Ruby implementations should put sensible values in there. (I've already talked with Charles Nutter on this, and I think they've changed JRuby's values to be more autoconf-compatible.) > Now, the platform designation for a gem indicates what > hareware/os it can run on. So mygem-1.0_jvm-1.4 will run on any > Java platform with version 1.4 or better. mygem-1.0_x86-macos-10 > will run on any version of MacOS X running on Intel hardware. > Since you can produce universal binaries on a mac that run on > either Intel or PowerPC, I would suggest that > mygem-1.0_uni-macos-10 would be a gem with universal binaries. I'd rather have everything spelled-out since that's easier to read, mygem-1.0-Universal-MacOSX-10.4. (Is there a defacto standard for naming packages like this?) > (Note that proposed naming scheme for gem file names. Will this > be a backwards compatibility issue? I don't think so. The gem > file name is just so we don't have file names for different > platforms that collide. I suspect that RubyGems will get the real > platform info from the gemspec itself). RubyGems shouldn't allow gems to be indexed (repository side) if their names don't match their internal metadata. > So, that's how we designate platforms. How will gems choose a > platform (more or less) automatically. > > Here's the selection process. Gems will know what platform its > running on (note to self: do we have to handle cross platform > installations?). > > [...] > > We will probably need a way to override the default platform > selection. I would recommend making the override available for > only explicitly installed gems (not for gems that are installed > automatically because they are dependencies). I think the override should apply to all gems installed, rather than only explicitly listed gems. There's at least one Rubyist who has gems installed on a disk shared by multiple machines. Having to manually install all dependencies would make automation a real pain. Also, this change might require changes in the local gem directory's name, mygem-1.0-Universal-MacOSX-10.4 instead of mygem-1.0 to allow cross-platform gems to live side by side. From jim at weirichhouse.org Tue Apr 24 22:13:27 2007 From: jim at weirichhouse.org (Jim Weirich) Date: Tue, 24 Apr 2007 22:13:27 -0400 Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> Message-ID: <462EB947.3090604@weirichhouse.org> Eric Hodel wrote: > On Apr 23, 2007, at 19:14, Jim Weirich wrote: > >> I haven't seen the results of tattle yet (perhaps Chad would like >> to share the gathered data) > > Its downloadable from: http://tattle.rubygarden.org/ Thanks. Going over the tattle data is interesting. And it raises a number of questions. (1) Do we need to differentiate between the various ix86 hardware architectures (e.g. i386, i486, i586, i686)? If not, fine. If so, then when choosing among available platformed varients, a i686 platform should be able to choose any of the iX86 variants, but a i486 would only be able to choose between i386 and i486 variants. (Is that correct?) In any case, X86_64 would have to be distinct from all the others. (2) What's up with Darwin8.8.1 stuff. My Mac claims to be 10.4.9, but Ruby is Darwin8.8.1. Is the 8.8.1 the BSD version, not the Mac OS version? (3) Sheesh, 17% of the respondents are running RubyGems 0.8.11. Just haven't upgraded? ... or technical issues with later version causing problems? (inquiring minds want to know). (4) Woah ... the prefix data looks a little revealing. Perhaps that shouldn't be on the download page (i.e. I now know where one prominent JRuby developer keeps his JRuby installation). (5) I'm guessing that 'target' is the platform Ruby is intended to run on and 'host' is the platform where it was compiled. Is that right? -- -- Jim Weirich jim at weirichhouse.org http://onestepback.org -- In theory, practice and theory are the same. -- In practice, they are different. From jim at weirichhouse.org Tue Apr 24 22:13:46 2007 From: jim at weirichhouse.org (Jim Weirich) Date: Tue, 24 Apr 2007 22:13:46 -0400 Subject: [Rubygems-developers] Platform Specification and Auto-selecting the Platform In-Reply-To: <26069771-B87F-4154-B72D-8E76D5D2C9CD@segment7.net> References: <462D6820.6070104@weirichhouse.org> <26069771-B87F-4154-B72D-8E76D5D2C9CD@segment7.net> Message-ID: <462EB95A.4060703@weirichhouse.org> Eric Hodel wrote: > Gem::SourceInfoCache.cache_data[...].source_index.map { ... }.uniq Dude! You Rock! > Don't forget Universal. Noted. > It should all be in Config::CONFIG under the TARGET_* values. Ruby > implementations should put sensible values in there. (I've already > talked with Charles Nutter on this, and I think they've changed > JRuby's values to be more autoconf-compatible.) The tattle data includes this data and is very interesting. But I'll comment on that in a separate thread. > I'd rather have everything spelled-out since that's easier to read, > mygem-1.0-Universal-MacOSX-10.4. (Is there a defacto standard for > naming packages like this?) Hmmmm ... makes for *really* long file names, but I agree. I would probably not do the mixed case thing tho. The only standard that I'm aware of in this space is the triple of hardware-vendor-os from the GNU autoconfigure stuff. > RubyGems shouldn't allow gems to be indexed (repository side) if > their names don't match their internal metadata. You're right. Any other choice would probably be regretted in the long run. > I think the override should apply to all gems installed, rather than > only explicitly listed gems. There's at least one Rubyist who has > gems installed on a disk shared by multiple machines. Ahh, I was thinking of the one-off case where a particular choice was made one a single gem that didn't work for some reason. I think your use case is more along the lines of a cross platform install, which is an important use cose. So noted. > Also, this change might require changes in the local gem directory's > name, mygem-1.0-Universal-MacOSX-10.4 instead of mygem-1.0 to allow > cross-platform gems to live side by side. I think it does that now. I just installed the x10-cm17a gem for msinw32 (on my Mac ... heh) and it included the platform name in the gem directory. -- -- Jim Weirich jim at weirichhouse.org http://onestepback.org -- In theory, practice and theory are the same. -- In practice, they are different. From drbrain at segment7.net Wed Apr 25 00:22:51 2007 From: drbrain at segment7.net (Eric Hodel) Date: Tue, 24 Apr 2007 21:22:51 -0700 Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: <462EB947.3090604@weirichhouse.org> References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> <462EB947.3090604@weirichhouse.org> Message-ID: On Apr 24, 2007, at 19:13, Jim Weirich wrote: > Eric Hodel wrote: >> On Apr 23, 2007, at 19:14, Jim Weirich wrote: >> >>> I haven't seen the results of tattle yet (perhaps Chad would like >>> to share the gathered data) >> >> Its downloadable from: http://tattle.rubygarden.org/ > > Thanks. > > Going over the tattle data is interesting. And it raises a number of > questions. > > (1) Do we need to differentiate between the various ix86 hardware > architectures (e.g. i386, i486, i586, i686)? If not, fine. If so, > then > when choosing among available platformed varients, a i686 platform > should be able to choose any of the iX86 variants, but a i486 would > only > be able to choose between i386 and i486 variants. (Is that correct?) I think the distinction is bogus. While its possible, I really doubt there's any Ruby-C code that requires a specific processor in the x86 family. > In any case, X86_64 would have to be distinct from all the others. Yes. > (2) What's up with Darwin8.8.1 stuff. My Mac claims to be 10.4.9, but > Ruby is Darwin8.8.1. Is the 8.8.1 the BSD version, not the Mac OS > version? Its the Darwin version. 10.4 is Darwin 8, 10.3 is Darwin 7, etc. See also: http://blog.segment7.net/articles/2007/01/10/tattle-host-os > (3) Sheesh, 17% of the respondents are running RubyGems 0.8.11. Just > haven't upgraded? ... or technical issues with later version causing > problems? (inquiring minds want to know). Likely, laziness. > (4) Woah ... the prefix data looks a little revealing. Perhaps that > shouldn't be on the download page (i.e. I now know where one prominent > JRuby developer keeps his JRuby installation). It doesn't matter, its not a secret. > (5) I'm guessing that 'target' is the platform Ruby is intended to run > on and 'host' is the platform where it was compiled. Is that right? I'm guessing the same. The autoconf documentation would say for sure. From jim at weirichhouse.org Wed Apr 25 00:33:07 2007 From: jim at weirichhouse.org (Jim Weirich) Date: Wed, 25 Apr 2007 00:33:07 -0400 Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> <462EB947.3090604@weirichhouse.org> Message-ID: <462EDA03.4080900@weirichhouse.org> Eric Hodel wrote: > On Apr 24, 2007, at 19:13, Jim Weirich wrote: >> (1) Do we need to differentiate between the various ix86 hardware >> architectures (e.g. i386, i486, i586, i686)? > I think the distinction is bogus. While its possible, I really doubt > there's any Ruby-C code that requires a specific processor in the x86 > family. My impression was that is a compile time thing. IOW, if I tell the compiler to enable i686 code generation, it might omit opcodes that are not available on earlier processors. I think that the position we should take is that if you want that level of optimization, compile it yourself. If you are making a gem for general distribution, compile it at a i386 level for broad compatibility. >> (2) What's up with Darwin8.8.1 stuff. My Mac claims to be 10.4.9, but >> Ruby is Darwin8.8.1. Is the 8.8.1 the BSD version, not the Mac OS >> version? > > Its the Darwin version. 10.4 is Darwin 8, 10.3 is Darwin 7, etc. Hmmm ... that's as bad as Sun's versioning schemes. Oh wait, I take that back. Nothing's that bad. -- -- Jim Weirich jim at weirichhouse.org http://onestepback.org -- In theory, practice and theory are the same. -- In practice, they are different. From jim at weirichhouse.org Wed Apr 25 00:36:18 2007 From: jim at weirichhouse.org (Jim Weirich) Date: Wed, 25 Apr 2007 00:36:18 -0400 Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: <462EDA03.4080900@weirichhouse.org> References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> <462EB947.3090604@weirichhouse.org> <462EDA03.4080900@weirichhouse.org> Message-ID: <462EDAC2.8030006@weirichhouse.org> Jim Weirich wrote: > [...] IOW, if I tell the > compiler to enable i686 code generation, it might omit opcodes that are > not available on earlier processors. Heh, I meant 'emit', not 'omit'. Changes the meaning quite a bit. -- -- Jim Weirich jim at weirichhouse.org http://onestepback.org -- In theory, practice and theory are the same. -- In practice, they are different. From hgs at dmu.ac.uk Wed Apr 25 04:57:22 2007 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Wed, 25 Apr 2007 09:57:22 +0100 (WEST) Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: <462EB947.3090604@weirichhouse.org> References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> <462EB947.3090604@weirichhouse.org> Message-ID: On Tue, 24 Apr 2007, Jim Weirich wrote: > Eric Hodel wrote: > > On Apr 23, 2007, at 19:14, Jim Weirich wrote: > > > >> I haven't seen the results of tattle yet (perhaps Chad would like > >> to share the gathered data) > > > > Its downloadable from: http://tattle.rubygarden.org/ I don't see a download there, but I see a display of this information. Incidentally, the graph bars don't work with large print, which bleeds outside them and then gets out of sync with them. I expect that is not easy to fix. SVG perhaps? > Thanks. > > Going over the tattle data is interesting. And it raises a number of > questions. [...] > (3) Sheesh, 17% of the respondents are running RubyGems 0.8.11. Just > haven't upgraded? ... or technical issues with later version causing > problems? (inquiring minds want to know). We don't know from what is displayed when these readings were taken. I haven't run tattle for ages. I'd suggest a link on that page to instructions, because I've forgotten what to do. A 3D graph showing time might be interesting, but nontrivial to produce > Hugh From drnicwilliams at gmail.com Wed Apr 25 05:56:51 2007 From: drnicwilliams at gmail.com (Nic Williams) Date: Wed, 25 Apr 2007 11:56:51 +0200 Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> <462EB947.3090604@weirichhouse.org> Message-ID: <44b555bb0704250256l4148b0abk35d8575c4931c9bf@mail.gmail.com> I also don't imagine the graphs showing significant deployment data, vs development box data. Thus all the mswin/darwin results. Nic On 4/25/07, Hugh Sasse wrote: > > On Tue, 24 Apr 2007, Jim Weirich wrote: > > > Eric Hodel wrote: > > > On Apr 23, 2007, at 19:14, Jim Weirich wrote: > > > > > >> I haven't seen the results of tattle yet (perhaps Chad would like > > >> to share the gathered data) > > > > > > Its downloadable from: http://tattle.rubygarden.org/ > > I don't see a download there, but I see a display of this > information. Incidentally, the graph bars don't work with large > print, which bleeds outside them and then gets out of sync with > them. I expect that is not easy to fix. SVG perhaps? > > > Thanks. > > > > Going over the tattle data is interesting. And it raises a number of > > questions. > [...] > > (3) Sheesh, 17% of the respondents are running RubyGems 0.8.11. Just > > haven't upgraded? ... or technical issues with later version causing > > problems? (inquiring minds want to know). > > We don't know from what is displayed when these readings were taken. > I haven't run tattle for ages. I'd suggest a link on that page > to instructions, because I've forgotten what to do. A 3D graph > showing time might be interesting, but nontrivial to produce > > > Hugh > _______________________________________________ > Rubygems-developers mailing list > Rubygems-developers at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubygems-developers > -- Dr Nic Williams http://www.drnicwilliams.com - Ruby/Rails/Javascript/Web2.0 skype: nicwilliams (p) +61 7 3102 3237 (Finds me anywhere in the world, via Skype) (m) +4673 768 1389 (Swedish mobile) (f) +61 7 3305 7572 (sends fax to my email) Bj?rnsonsgatan 153, 16 844 Bromma, Sweden -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubygems-developers/attachments/20070425/b315b53c/attachment.html From phurley at gmail.com Wed Apr 25 09:11:39 2007 From: phurley at gmail.com (Patrick Hurley) Date: Wed, 25 Apr 2007 09:11:39 -0400 Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: <462EDA03.4080900@weirichhouse.org> References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> <462EB947.3090604@weirichhouse.org> <462EDA03.4080900@weirichhouse.org> Message-ID: <554ac39c0704250611l5f49c246y110ff61ade63cd2a@mail.gmail.com> On 4/25/07, Jim Weirich wrote: > I think that the position we should take is that if you want that level > of optimization, compile it yourself. If you are making a gem for > general distribution, compile it at a i386 level for broad > compatibility. Couple of thoughts: 1. Other than embedded systems (where compiling is a common requirement) who really has a 386 system around? And 486 optimizations (more about code ordering than opcodes) helps all of the recent architectures -- so I would vote for using 486 as the standard build level. 2. Right now the platform names are coming from rbconfig//autoconf. To require/encourage people to distribute a 486 (or 386) get, they would need to use a ruby built at that level or we would need to provide tools to assist. pth From charles.nutter at sun.com Wed Apr 25 15:26:45 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Wed, 25 Apr 2007 14:26:45 -0500 Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: <462EB947.3090604@weirichhouse.org> References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> <462EB947.3090604@weirichhouse.org> Message-ID: <462FAB75.1010101@sun.com> Jim Weirich wrote: > (4) Woah ... the prefix data looks a little revealing. Perhaps that > shouldn't be on the download page (i.e. I now know where one prominent > JRuby developer keeps his JRuby installation). I tend to agree with this one. In most data-gathering software it's considered a big no-no to report personally identifiable information. I'm not particularly enthused that the structure of my JRuby path shows up in there. I'd also say this information is pretty useless to report, since there's an infinite number of places people might have Ruby installed From charles.nutter at sun.com Wed Apr 25 15:33:03 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Wed, 25 Apr 2007 14:33:03 -0500 Subject: [Rubygems-developers] Platform Specification and Auto-selecting the Platform In-Reply-To: <26069771-B87F-4154-B72D-8E76D5D2C9CD@segment7.net> References: <462D6820.6070104@weirichhouse.org> <26069771-B87F-4154-B72D-8E76D5D2C9CD@segment7.net> Message-ID: <462FACEF.9000008@sun.com> Eric Hodel wrote: > It should all be in Config::CONFIG under the TARGET_* values. Ruby > implementations should put sensible values in there. (I've already > talked with Charles Nutter on this, and I think they've changed > JRuby's values to be more autoconf-compatible.) Yeah, we finally got this changed in the 0.9.9 release. It makes a best attempt to match the format of Ruby's values (like i386-java1.6 for arch, or just java1.6 format for when the processor doesn't matter (like the java version used to build something). This means we've managed to eliminate the flat "java" versions in favor of ones that provide a bit more platform information, but others couldn't be corrected (i.e. the JVM's "nice" names for operating systems and vendors). The values are described in my comment here: http://jira.codehaus.org/browse/JRUBY-454#action_93130 If there are suggestions on how to improve any of these, now's the time to let us know. We're pushing toward 1.0 now. - Charlie From drbrain at segment7.net Thu Apr 26 02:21:50 2007 From: drbrain at segment7.net (Eric Hodel) Date: Wed, 25 Apr 2007 23:21:50 -0700 Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> <462EB947.3090604@weirichhouse.org> Message-ID: <5F2FDC42-046F-4785-9008-A4DB3835692B@segment7.net> On Apr 25, 2007, at 01:57, Hugh Sasse wrote: > On Tue, 24 Apr 2007, Jim Weirich wrote: > >> Eric Hodel wrote: >>> On Apr 23, 2007, at 19:14, Jim Weirich wrote: >>> >>>> I haven't seen the results of tattle yet (perhaps Chad would like >>>> to share the gathered data) >>> >>> Its downloadable from: http://tattle.rubygarden.org/ > > I don't see a download there Its the three icons, XML, CSV, YAML From hgs at dmu.ac.uk Thu Apr 26 04:31:33 2007 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Thu, 26 Apr 2007 09:31:33 +0100 (WEST) Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: <5F2FDC42-046F-4785-9008-A4DB3835692B@segment7.net> References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> <462EB947.3090604@weirichhouse.org> <5F2FDC42-046F-4785-9008-A4DB3835692B@segment7.net> Message-ID: On Wed, 25 Apr 2007, Eric Hodel wrote: > On Apr 25, 2007, at 01:57, Hugh Sasse wrote: > > > On Tue, 24 Apr 2007, Jim Weirich wrote: > > > >> Eric Hodel wrote: > >>> On Apr 23, 2007, at 19:14, Jim Weirich wrote: > >>> > >>>> I haven't seen the results of tattle yet (perhaps Chad would like > >>>> to share the gathered data) > >>> > >>> Its downloadable from: http://tattle.rubygarden.org/ > > > > I don't see a download there > > Its the three icons, XML, CSV, YAML Yes, spotted those quite a bit later. I think it's because they were in the grey bar that I didn't see them. And that my vision isn't up to Mil Spec :-) Thanks. Hugh From ryand-ruby at zenspider.com Thu Apr 26 04:07:33 2007 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Thu, 26 Apr 2007 01:07:33 -0700 Subject: [Rubygems-developers] Platform Specification and Auto-selecting the Platform In-Reply-To: <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> Message-ID: On Apr 24, 2007, at 14:24 , Eric Hodel wrote: > On Apr 23, 2007, at 19:14, Jim Weirich wrote: > >> I haven't seen the results of tattle yet (perhaps Chad would like >> to share the gathered data) > > Its downloadable from: http://tattle.rubygarden.org/ As a complete aside, I just wrote some code to collapse some of the tattle info down to more aggregated data (too many version numbers): % ./blah.rb 458: x86-linux-gnu 360: x86-apple-darwin 274: x86-pc-mswin 165: powerpc-apple-darwin 27: x86-freebsd 17: sparc-sun-solaris 8: x86-pc-cygwin 8: java 7: x86-pc-solaris 7: x86-unknown-openbsd 3: x86-linux 2: powerpc-linux-gnu 2: amd64-freebsd 1: x86-mingw 1: powerpc64-linux-gnu Much more interesting to me now. (go apple!) From drbrain at segment7.net Thu Apr 26 14:14:53 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 26 Apr 2007 11:14:53 -0700 Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: <462FAB75.1010101@sun.com> References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> <462EB947.3090604@weirichhouse.org> <462FAB75.1010101@sun.com> Message-ID: <7D423F6D-15EE-42F8-8255-0891BEB70FE7@segment7.net> On Apr 25, 2007, at 12:26, Charles Oliver Nutter wrote: > Jim Weirich wrote: >> (4) Woah ... the prefix data looks a little revealing. Perhaps that >> shouldn't be on the download page (i.e. I now know where one >> prominent >> JRuby developer keeps his JRuby installation). > > I tend to agree with this one. In most data-gathering software it's > considered a big no-no to report personally identifiable information. > I'm not particularly enthused that the structure of my JRuby path > shows > up in there. I'd also say this information is pretty useless to > report, > since there's an infinite number of places people might have Ruby > installed How exactly is it sensitive? If I'm able to run code on the box I can find ruby, via rbconfig.rb or traversing the filesystem. On the other hand, if I had a non-ruby vector for getting into your machine, I'm sure there's lots of other stuff I'd compromise before I got around to messing with your ruby installation. From charles.nutter at sun.com Thu Apr 26 14:29:19 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Thu, 26 Apr 2007 13:29:19 -0500 Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: <7D423F6D-15EE-42F8-8255-0891BEB70FE7@segment7.net> References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> <462EB947.3090604@weirichhouse.org> <462FAB75.1010101@sun.com> <7D423F6D-15EE-42F8-8255-0891BEB70FE7@segment7.net> Message-ID: <4630EF7F.10201@sun.com> Eric Hodel wrote: > How exactly is it sensitive? If I'm able to run code on the box I > can find ruby, via rbconfig.rb or traversing the filesystem. On the > other hand, if I had a non-ruby vector for getting into your machine, > I'm sure there's lots of other stuff I'd compromise before I got > around to messing with your ruby installation. I just don't like personally-identifiable information about my filesystem layout to be published without my knowledge. Someone noisier than me will start causing trouble for that eventually. Sure, it's not a big deal, but it's exactly the kind of thing security folks frown on. Also, how is this information even useful? Is there a good reason to grab and publish the install prefix for every Ruby that tattles? - Charlie From Daniel.Berger at qwest.com Thu Apr 26 14:34:15 2007 From: Daniel.Berger at qwest.com (Daniel Berger) Date: Thu, 26 Apr 2007 12:34:15 -0600 Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGemsplaform thread) In-Reply-To: <7D423F6D-15EE-42F8-8255-0891BEB70FE7@segment7.net> References: <462D6820.6070104@weirichhouse.org><10937DF3-10C0-4500-8983-97CF D2F22D04@segment7.net><462EB947.3090604@weirichhouse.org> <462FAB75.1010101@sun.com> <7D423F6D-15EE-42F8-8255-0891BEB70FE7@segment7.net> Message-ID: <4630F0A7.4060602@qwest.com> Eric Hodel wrote: > On Apr 25, 2007, at 12:26, Charles Oliver Nutter wrote: >> Jim Weirich wrote: >>> (4) Woah ... the prefix data looks a little revealing. Perhaps that >>> shouldn't be on the download page (i.e. I now know where one >>> prominent >>> JRuby developer keeps his JRuby installation). >> I tend to agree with this one. In most data-gathering software it's >> considered a big no-no to report personally identifiable information. >> I'm not particularly enthused that the structure of my JRuby path >> shows >> up in there. I'd also say this information is pretty useless to >> report, >> since there's an infinite number of places people might have Ruby >> installed > > How exactly is it sensitive? If I'm able to run code on the box I > can find ruby, via rbconfig.rb or traversing the filesystem. On the > other hand, if I had a non-ruby vector for getting into your machine, > I'm sure there's lots of other stuff I'd compromise before I got > around to messing with your ruby installation. Little did you know that he's running RubyOS! Finding his Ruby intepreter would bring down the whole shebang. Literally. It's a joke people! Dan From drbrain at segment7.net Thu Apr 26 15:53:07 2007 From: drbrain at segment7.net (Eric Hodel) Date: Thu, 26 Apr 2007 12:53:07 -0700 Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: <4630EF7F.10201@sun.com> References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> <462EB947.3090604@weirichhouse.org> <462FAB75.1010101@sun.com> <7D423F6D-15EE-42F8-8255-0891BEB70FE7@segment7.net> <4630EF7F.10201@sun.com> Message-ID: <67CA79BE-3BEC-4CA4-A30F-81D334761875@segment7.net> On Apr 26, 2007, at 11:29, Charles Oliver Nutter wrote: > Eric Hodel wrote: >> How exactly is it sensitive? If I'm able to run code on the box I >> can find ruby, via rbconfig.rb or traversing the filesystem. On the >> other hand, if I had a non-ruby vector for getting into your machine, >> I'm sure there's lots of other stuff I'd compromise before I got >> around to messing with your ruby installation. > > I just don't like personally-identifiable information about my > filesystem layout to be published without my knowledge. Someone > noisier > than me will start causing trouble for that eventually. Sure, it's > not a > big deal, but it's exactly the kind of thing security folks frown on. > Also, how is this information even useful? Is there a good reason to > grab and publish the install prefix for every Ruby that tattles? $ tattle -h Usage: tattle report # Print config data without sending tattle post # Post config data (this is the default) From hgs at dmu.ac.uk Fri Apr 27 04:51:00 2007 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Fri, 27 Apr 2007 09:51:00 +0100 (WEST) Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: <67CA79BE-3BEC-4CA4-A30F-81D334761875@segment7.net> References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> <462EB947.3090604@weirichhouse.org> <462FAB75.1010101@sun.com> <7D423F6D-15EE-42F8-8255-0891BEB70FE7@segment7.net> <4630EF7F.10201@sun.com> <67CA79BE-3BEC-4CA4-A30F-81D334761875@segment7.net> Message-ID: On Thu, 26 Apr 2007, Eric Hodel wrote: > On Apr 26, 2007, at 11:29, Charles Oliver Nutter wrote: > > Eric Hodel wrote: > >> How exactly is it sensitive? If I'm able to run code on the box I > >> can find ruby, via rbconfig.rb or traversing the filesystem. On the [...] > > > > I just don't like personally-identifiable information about my > > filesystem layout to be published without my knowledge. Someone [...] > > $ tattle -h > Usage: > tattle report # Print config data without sending > tattle post # Post config data (this is the default) Yes, but what do you mean by posting that? "Don't post if you don't want to reveal personal data?" Well, what if you want to reveal the data that isn't personal, for all the reasons tattle was invented? I think that if personal data (particularly names embedded in paths) is going to be sent then tattle should give people the information about what is to be sent. Various choices about this come to mind: 1 `tattle psst` uses the data from tattle report, and doesn't generate the report itself. This give people time to edit the data to obscure information. But that makes the data less accurate, given: "To err is human. [To really mess things up, involve a computer.]". 2 'tattle post` gathers data as now, but displays it and asks before posting. This is interactive, more verbose than Unix conventions. 3 'tattle post' gets more options about what it may send, so one can turn off various parameters. Complicates the code, and the interface. 4 `tattle` with no options should be the same as `tattle -h` instead of `tattle post` Again runs against Unix culture but is more "first, do no harm". Security is 1/convenience, as they say. Are any of the above acceptable changes, or is there something better one could do? Bizarre thought: tattle really only answers the positive side of the question. What about providing a form (with CAPTCHA or something) to find out how many people don't install ruby on their platform and why not? Hugh From drbrain at segment7.net Fri Apr 27 14:41:40 2007 From: drbrain at segment7.net (Eric Hodel) Date: Fri, 27 Apr 2007 11:41:40 -0700 Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> <462EB947.3090604@weirichhouse.org> <462FAB75.1010101@sun.com> <7D423F6D-15EE-42F8-8255-0891BEB70FE7@segment7.net> <4630EF7F.10201@sun.com> <67CA79BE-3BEC-4CA4-A30F-81D334761875@segment7.net> Message-ID: On Apr 27, 2007, at 01:51, Hugh Sasse wrote: > On Thu, 26 Apr 2007, Eric Hodel wrote: >> On Apr 26, 2007, at 11:29, Charles Oliver Nutter wrote: >>> Eric Hodel wrote: >>>> How exactly is it sensitive? If I'm able to run code on the box I >>>> can find ruby, via rbconfig.rb or traversing the filesystem. On >>>> the > [...] >>> >>> I just don't like personally-identifiable information about my >>> filesystem layout to be published without my knowledge. Someone > [...] >> >> $ tattle -h >> Usage: >> tattle report # Print config data without sending >> tattle post # Post config data (this is the default) > > Yes, but what do you mean by posting that? If you find tattle is reporting information you don't want public after you've published it, you should have checked out what it was doing first and not run tattle. (While the first release of tattle didn't have the report option, it was still simple enough to visit the tattle report page or inspect the source to discover what was being reported.) From charles.nutter at sun.com Fri Apr 27 16:57:31 2007 From: charles.nutter at sun.com (Charles Oliver Nutter) Date: Fri, 27 Apr 2007 15:57:31 -0500 Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> <462EB947.3090604@weirichhouse.org> <462FAB75.1010101@sun.com> <7D423F6D-15EE-42F8-8255-0891BEB70FE7@segment7.net> <4630EF7F.10201@sun.com> <67CA79BE-3BEC-4CA4-A30F-81D334761875@segment7.net> Message-ID: <463263BB.4070103@sun.com> Eric Hodel wrote: > If you find tattle is reporting information you don't want public > after you've published it, you should have checked out what it was > doing first and not run tattle. > > (While the first release of tattle didn't have the report option, it > was still simple enough to visit the tattle report page or inspect > the source to discover what was being reported.) If you didn't want a security hole in your system you should have read all the code first. Sound a little silly? I still haven't heard how the prefix information is useful, or why it couldn't just be eliminated/turned off now that a few people have raised concerns about it. What use is this information? Why keep it? - Charlie From thewoolleyman at gmail.com Sat Apr 28 13:54:54 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 28 Apr 2007 10:54:54 -0700 Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: <463263BB.4070103@sun.com> References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> <462EB947.3090604@weirichhouse.org> <462FAB75.1010101@sun.com> <7D423F6D-15EE-42F8-8255-0891BEB70FE7@segment7.net> <4630EF7F.10201@sun.com> <67CA79BE-3BEC-4CA4-A30F-81D334761875@segment7.net> <463263BB.4070103@sun.com> Message-ID: On 4/27/07, Charles Oliver Nutter wrote: > Eric Hodel wrote: > > If you find tattle is reporting information you don't want public > > after you've published it, you should have checked out what it was > > doing first and not run tattle. > > > > (While the first release of tattle didn't have the report option, it > > was still simple enough to visit the tattle report page or inspect > > the source to discover what was being reported.) > > If you didn't want a security hole in your system you should have read > all the code first. > > Sound a little silly? > > I still haven't heard how the prefix information is useful, or why it > couldn't just be eliminated/turned off now that a few people have raised > concerns about it. What use is this information? Why keep it? > > - Charlie I agree with everything Charlie just said :) -- Chad From chad at chadfowler.com Sat Apr 28 19:29:54 2007 From: chad at chadfowler.com (Chad Fowler) Date: Sat, 28 Apr 2007 17:29:54 -0600 Subject: [Rubygems-developers] Reviewing the Tattle Data (was RubyGems plaform thread) In-Reply-To: <462EB947.3090604@weirichhouse.org> References: <462D6820.6070104@weirichhouse.org> <10937DF3-10C0-4500-8983-97CFD2F22D04@segment7.net> <462EB947.3090604@weirichhouse.org> Message-ID: On 4/24/07, Jim Weirich wrote: > > (4) Woah ... the prefix data looks a little revealing. Perhaps that > shouldn't be on the download page (i.e. I now know where one prominent > JRuby developer keeps his JRuby installation). > I've removed it from the reports. Chad From thewoolleyman at gmail.com Sat Apr 28 20:14:26 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Sat, 28 Apr 2007 17:14:26 -0700 Subject: [Rubygems-developers] Error when remotely listing ActiveRecord-JDBC with RubyGems 0.9.2 Message-ID: Hi, I get the following error when listing ActiveRecord-JDBC remotely with RubyGems 0.9.2. It happens on OSX and Linux, but not windows. It doesn't happen on RubyGems 0.9.0. There also looks like there's a related bug which is open: http://rubyforge.org/tracker/index.php?func=detail&aid=8359&group_id=126&atid=575 Here's the error. It also occurs when using plain 'activerecord' as the search string, but I think this is because ActiveRecord-JDBC is matching the substring, because you can see that activerecord-mimer does not get an error: /> gem --version 0.9.2 /> gem list ActiveRecord-JDBC --remote --debug --backtrace Exception `Errno::ENOENT' at /usr/local/lib/ruby/site_ruby/1.8/rubygems/config_file.rb:51 - No such file or directory - /Users/pivotal/.gemrc *** REMOTE GEMS *** Exception `NoMethodError' at /usr/local/lib/ruby/site_ruby/1.8/rubygems/version.rb:136 - private method `scan' called for # ERROR: While executing gem ... (NoMethodError) private method `scan' called for # /usr/local/lib/ruby/site_ruby/1.8/rubygems/version.rb:136:in `to_ints' /usr/local/lib/ruby/site_ruby/1.8/rubygems/version.rb:147:in `<=>' /usr/local/lib/ruby/site_ruby/1.8/rubygems/version.rb:198 /usr/local/lib/ruby/site_ruby/1.8/rubygems/version.rb:292:in `satisfy?' /usr/local/lib/ruby/site_ruby/1.8/rubygems/version.rb:283:in `satisfied_by?' /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `all?' /usr/local/lib/ruby/site_ruby/1.8/rubygems/version.rb:283:in `satisfied_by?' /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:210:in `search' /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:208:in `search' /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:109:in `search' /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `map' /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:108:in `search' /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:49:in `search' /usr/local/lib/ruby/site_ruby/1.8/rubygems/gem_commands.rb:806:in `execute' /usr/local/lib/ruby/site_ruby/1.8/rubygems/gem_commands.rb:886:in `execute' /usr/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:70:in `invoke' /usr/local/lib/ruby/site_ruby/1.8/rubygems/cmd_manager.rb:120:in `process_args' /usr/local/lib/ruby/site_ruby/1.8/rubygems/cmd_manager.rb:91:in `run' /usr/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:30:in `run' /usr/local/bin/gem:23 /> gem list activerecord-mimer --remote *** REMOTE GEMS *** activerecord-mimer (0.0.4, 0.0.3, 0.0.2, 0.0.1) Mimer support for ActiveRecord. /> From thewoolleyman at gmail.com Mon Apr 30 15:43:16 2007 From: thewoolleyman at gmail.com (Chad Woolley) Date: Mon, 30 Apr 2007 12:43:16 -0700 Subject: [Rubygems-developers] Error when remotely listing ActiveRecord-JDBC with RubyGems 0.9.2 In-Reply-To: References: Message-ID: Hi, I think this is actually a somewhat serious problem - anyone who tries to do a remote gem list on 'activerecord' with RubGems 0.9.2+ will get an exception. I've got a thread going on the Jruby and jruby-extra lists to have them look into it, but I'd like to fix the related problem in RubyGems. Even if Jruby fixes this particular gem, it could still theoretically happen with another gem in the future - my upcoming rails-but-even-l337er gem, for example. (that was a joke) The real problem that I see is the wildcard matching of the remote gem list command, which cannot currently be overridden. If it could, then I could just request an exact match like /^activerecord$/, and not even pick up the ActiveRecord-jdbc gem. So, I could hack this in by making a change to the Gem::Commands::ListCommand#execute method, and trying to make it "detect" whether some regexp was passed as the argument. It currently matches /^#{string}/, which is the wildcard matching at the root of the problem. However, fixing this proved to be tricky to do without breaking any of the existing behavior. Should the gem list search term be the forward-slash-delimited regexp style? If so, how to detect that? Eval'ing and checking the type could cause a syntax error if the eval rails. Passing it to Regexp.compile to see if it compiles would require stripping the slash delimiters (and any other trailing flags). There could also be a separate command-line flag to the 'gem list' command to specify and exact name match instead of a wildcard - perhaps '--exact-match'? Alternately, we could fix whatever it was that allowed this invalid gem to be uploaded and indexed on the rubygems mirrors, but I have no idea where to start on that one. I looked at the ActiveRecord-JDBC gem source, and I see nothing suspicious - it's just a standard Hoe config. Not even any mention of YAML::Private anywhere. So, to summarize, I'd be glad to help fix this, but I'd appreciate some direction from the devs so I don't waste time going down the wrong path. Thanks, Chad On 4/28/07, Chad Woolley wrote: > Hi, > > I get the following error when listing ActiveRecord-JDBC remotely with > RubyGems 0.9.2. It happens on OSX and Linux, but not windows. It > doesn't happen on RubyGems 0.9.0. There also looks like there's a > related bug which is open: > > http://rubyforge.org/tracker/index.php?func=detail&aid=8359&group_id=126&atid=575 > > Here's the error. It also occurs when using plain 'activerecord' as > the search string, but I think this is because ActiveRecord-JDBC is > matching the substring, because you can see that activerecord-mimer > does not get an error: > > /> gem --version > 0.9.2 > /> gem list ActiveRecord-JDBC --remote --debug --backtrace > Exception `Errno::ENOENT' at > /usr/local/lib/ruby/site_ruby/1.8/rubygems/config_file.rb:51 - No such > file or directory - /Users/pivotal/.gemrc > > *** REMOTE GEMS *** > Exception `NoMethodError' at > /usr/local/lib/ruby/site_ruby/1.8/rubygems/version.rb:136 - private > method `scan' called for # > ERROR: While executing gem ... (NoMethodError) > private method `scan' called for # > /usr/local/lib/ruby/site_ruby/1.8/rubygems/version.rb:136:in `to_ints' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/version.rb:147:in `<=>' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/version.rb:198 > /usr/local/lib/ruby/site_ruby/1.8/rubygems/version.rb:292:in `satisfy?' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/version.rb:283:in `satisfied_by?' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `all?' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/version.rb:283:in `satisfied_by?' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:210:in `search' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_index.rb:208:in `search' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:109:in `search' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `map' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:108:in `search' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/source_info_cache.rb:49:in `search' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/gem_commands.rb:806:in `execute' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/gem_commands.rb:886:in `execute' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/command.rb:70:in `invoke' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/cmd_manager.rb:120:in `process_args' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/cmd_manager.rb:91:in `run' > /usr/local/lib/ruby/site_ruby/1.8/rubygems/gem_runner.rb:30:in `run' > /usr/local/bin/gem:23 > /> gem list activerecord-mimer --remote > > *** REMOTE GEMS *** > > > activerecord-mimer (0.0.4, 0.0.3, 0.0.2, 0.0.1) > Mimer support for ActiveRecord. > /> > From gregory.t.brown at gmail.com Mon Apr 30 22:08:36 2007 From: gregory.t.brown at gmail.com (Gregory Brown) Date: Mon, 30 Apr 2007 22:08:36 -0400 Subject: [Rubygems-developers] Do you guys have Tattle Reports wishlist? Message-ID: Hi Chad, Eric, Jim, et. al It's been a while since I said I'd work on this at MWRC, but with Ruport 1.0 coming up around the corner, it's about time to get some quality examples of what it can do.The tattle data is a nice, fairly simple data set to work with, so it should be a good task to target. I've got a database dump, and I'm sure we can think up some reports, but I'd be interested in producing whatever is most important to the RubyGems developers. So if you have a wish list, let me know, and we'll see what we can do with it in the next couple weeks. -greg PS: Chad, I've CCed Mike, who is in charge of our Rails integration, I think it'll be easy to integrate reports right into the tattle rails app, but Mike would be the one to go to on that.