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 22:28
on 2017-02-23 20: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 19: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-25 23: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 20: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.