Installing Ruby (noob alert!)

Ruby
1

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.

2

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 :

for more general solution (ruby/debian/python…) perhaps :

(I have not try it)

for debian:

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 :slight_smile:

3

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.

4

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? :slight_smile:

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 … :slight_smile:

5

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.

6

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).

  1. 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…

7

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.

8

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…