Is there any hazard in trying to install Ruby 2.3, as in *all* of it, on a 64 bit Win7 machine? Background: I like my development systems to be network independent. I install Perl/Rakudo - I install the majority of its modules. For Debian, I have more than half the archives loaded. Thousands of Python modules loaded. I am in the process of starting a project where Ruby seems quicker and more efficient at least for major parts than my normal Perl. I want to be able to work unabated if I need to travel, or if the Comcast ISP goes down (frequently). It is trivial to parse the list of modules into an install script. The problem is that it seems there is alot of garbage and reptition. On my Debian system I simply mirrored the archive, but with over a half-million (before the mirror script broke) I dont want to load down the new system with 90% dross. I am not too familiar with the Ruby versioning system, so i do wonder about conflicts between differing modules if installed en masse. Is there a winnowing process or scripts available? I see that there is a site for listing the popularity of gems, but I see no way to simply download a list of the most 'popular' gems that have been downloaded at least 10,000 times or more.
on 2017-02-22 23:28
on 2017-02-23 21:23
Karta Larchmont wrote in post #1185586: > Is there a winnowing process or scripts available? I see that there is a > site for listing the popularity of gems, but I see no way to simply > download a list of the most 'popular' gems that have been downloaded at > least 10,000 times or more. get your own gem server : http://guides.rubygems.org/run-your-own-gem-server/ for more general solution (ruby/debian/python...) perhaps : https://gemfury.com/ (I have not try it) for debian: https://www.howtoforge.com/local_debian_ubuntu_mirror >I want to be able to work unabated if I need to travel, or if the Comcast > ISP goes down (frequently). GSM/4G + wifi share access point :)
on 2017-02-25 20:40
Thank you for that site. In Debian I was suing a mirror gem, than an unexpected update deprecated it. The problem with the mirror, is that it will take *every8 gem version, and frankly I dont know which versions to toss. The total exceed over 100Gb. My existing mirror seems to be working old, though its a couple of years old. I have it creating a large ruby 1.93 install for my 32 bit XP machines. I need something newer for my 64 bit Win7/Debian-Devuan machines - and that repo software seems just fine. However the itching question will remain on how to keep the local archive to manageable size. I dont need 50 different versions of a gem when only one or two will do. And the *last* gem mirror gem would fastidiously check the local archive and replace every gem that had been deleted before updating. I am not yet too familiar with Ruby mechanics, so the question is whether gem install --local foo will always install the *latest* version of the foo gem. My experience with Ruby 1.93 (MRI) is that it does defualt to the latest version. What I am unsure of is the testing. Ruby doesnt seem to verbosely test as well as Perl. Also, to avoid the difficulties of navigating a directory with a half million entries I have alphabetized them, which means I have to use --force. Or even whether that is even desirable. I could not compile one gem on Win32, but went to an earlier version on my old local mirror, and it installed (and apparently tested) fine. I am still confused by bundle and rvm - so I dont know hwere or how they apply in this situation. I am looking to install en masse. And am not even sure that this is something proactical or desirable: Will this drastically slow down Ruby? It doesnt seem to affect Perl, or even Python (though only a few thousand modules there). Of great help would be if there was a way of skipping the install of pre-existing modules, instead of compiling them and refusing to overwrite existing ones. Alot of time wasted there.
on 2017-02-26 00:45
I have not fully understood the problem domain there, but: > I am not yet too familiar with Ruby mechanics, so the > question is whether > gem install --local foo > will always install the *latest* version of the foo gem. You seem to want to have the latest version of gem xyz, right? I think that this is the default behaviour via "gem install" anyway. If you need a different version, you can always do at the least one of these two ways: -- Download the local .gem which you can obtain by downloading the remote gem. I use wget for this usually. It should work on windows too; at the least I think it did... last time I used msys/mingw was like 6 years ago or so. Windows hopefully got better during those years... don't they now have bash available or at the least make it simple to obtain and use bash? But I digress. In the worst case, one could click on the link on rubygems.org and then save the .gem file locally. -- I think you can also specify a specific version via the "gem" command. You can also run a gem server on your system, offering all those (local) gems that you then use. > I am still confused by bundle and rvm - so I dont know hwere > or how they apply in this situation I don't use either of them and have been using ruby since +10 years just fine. Gem works without any of them and gem is actually pretty good. > Also, to avoid the difficulties of navigating a directory with > a half million entries I have alphabetized them I don't entirely understand it. There are less than 130.000 gems on rubygems.org. The majority is probably old or unmaintained. I don't even know how anyone can reach that number, is your problem a real one? :-) I have about 213 gems locally here; using perhaps half of them. I think debian has about 30.000 packages registered. https://wiki.debian.org/ReproducibleBuilds About 25.000 are tracked by reproducible builds or so ... 23.000 seem to work there. I am not quite sure how you reach +500.000 files in one directory ... :)
on 2017-02-26 21:23
The Ruby Gem repo consists of *all* versions of gems. So 100k Gem varieties of gems, can easily lead to well over a half million packages. Unless there are newer changes or options to the latest version of gem-mirror (which I will be setting up under debian in the near future) - the default manner has been to only permit ALL gems to be downloaded. There was no way of filtering, and if any gems were deleted locally, they would be replaced whenever the mirror software was activated. As an example, the rabl gem has at least 70 versions. If I delete 69 of them they will be again downloaded before any updates. With the rack gem, v2.0 is 7k and its Rack.rb file is 0 bytes. v 1.6 has a 3.6k rack.rb and a gem size is 227k. So the 'latest' version of rack seems somehow crippled. This is a characteristic of many gems. Wild variations in sizes between versions on one hand, and also many succeeding versions with exactly the same file sizes, with the suspicion of no real changes internally. And this is what led me to question the Ruby versioning system. CPAN might have multiple versions of its modules, but they generally follow a progressive sequence, with minimal Perl versions. My suspicion is that many Ruby versions have *exact* requrements (req = 1.93 that would fail under 1.94, for example). I might be wrong about this, however. I am currently running MRI Ruby v1.9 and 2.3. I am wondering if there is a script that can flesh out all the useful from the useless gems. Say, delete all that are below v1.9 requirements. Are there any published lists of umaintained gems? That would also be helpful. This really wouldnt be an issue with one of my smaller systems, where typical installs of scripting languages would be only a few hundered modules. But I am looking for 'master' 32 and 64 bit development systems on my main machines, loaded to the gills. Perhaps an unusual situation. But here its a strategy which has allowed me to compile and get working numerous code that is difficult to get to function or compile on most other systems. The Win systems here are half Posix. I have Cygwin pretty much itegrated with the system though I make sure that the Ruby versions are kept seperate.
on 2017-04-06 01:37
Update: I am now installing Ruby on my Debian/Devuan 8 system. All is going fairly well. I currently have around 17,000 gems installed. And started running into some conflicts. I will be reducing the amount as time goes by, but want to be able to see which ones are really useful, if possible. Once again this systrem is designed to be NOT dependent on the net so it should carry as much locally as feasible. Now as expected with such a massive install, there are a few problems that I havent been able to google too easily: 1. Thor was giving errors at its latest version (19.4) so I moved it out of the gem dir, and its running on 19.1 - apparently fine. QUESTION - Is this the default mode for Ruby - if a newest version is simply removed (without going through the system uninstall) - will it default to the next latest version? (In other words is it safe to assume that Ruby is Like Perl and simply parses the gems in the directory structure rather than a central 'registry'. I understand there might be problems if the gem is called with a gem=ver rather than a gem=>ver argument). 2. Launchy gives a startup warning about wanting Version > 2. Well there are a few Launchy gems installed, all 2.0 or greater. QUESTION: Is Launchy a critical system file ( I didnt want to try my Thor method on it, as the name 'launchy' suggests it might be able to putz the gem launch methods... I am using "gem cleanup", which does lead to a few duplicates, with apparently fixed version requirements. Are those cast in stone? LAST QUESTION: Can module requirements be overridden on a *system wide* basis, at least for testing to see if say a Rails3 module might work on Rails4? If not, is there a specific place to edit in the gem file? Perhaps the Makefile, and recompile...
on 2017-04-06 08:50
> QUESTION - Is this the default mode for Ruby - if a newest version is > simply removed (without going through the system uninstall) - will it > default to the next latest version? Yes. Anything else would be a bug. If you have version 1.0.1, 1.0.2 and 1.0.3 installed and you specifically uninstall only version 1.0.3, then any require comment made should default to the highest version left - in this case 1.0.2. You can verify this for yourself: gem install sinatra --version 1.4.7 In a ruby script: require 'sinatra'; Sinatra::VERSION # => "1.4.7" Then do: gem install sinatra --version 1.4.8 In a ruby script: require 'sinatra'; Sinatra::VERSION # => "1.4.8" Then do: gem uninstall sinatra --version 1.4.8 And in a ruby script again: require 'sinatra'; Sinatra::VERSION # => "1.4.7" So you see that the versions remain unless you uninstall them.
on 2017-04-09 21:57
Thank you for the reassurance. I have been downloading and parsing the lists from best.gems org. Idea being, from having a mirror here, that there is alot of unmaintained crud - and that bestgems could be used as kind of a filter to get the gems that are at least being used by real users. Is there a filterable version of gem-mirror? In debian I can create a mirror based on distro and arch. Ideally I would be able to just parse for versions 1.93+, and 2.0+ and only for the x86/32+64 platform. And only the highest sub.version would be downloaded. For example, I see: foo-001.gem foo-1.01.gem foo-1.02.gem foo-2.01.gem foo-2.02.gem foo-2.03.gem foo-3.00.gem foo.3.01.gem My guesstimation here is that the major versions would be tied to Ruby versions. v3 would likely be for 2.3 (if actively maintained), and that 3.01 is the latest. foo-2.03 is likely to be for v1.93, and the latest version for that. And that here, at least i should be able to delete all v1 foo gems. As an example, when I try to locally install on my debian 32 bit 1.93 system, alot of gems wount work. Specifying a lower major version usually does the trick. But often minor ones will work too..... However there are times when foo-001 seems to be vastly larger than other foos, suggesting it might be a dependency in itself...