[BioRuby] Ruby installation

[Iain Barnett]

Pjotr,

Firstly, you're correct, I wasn't using Ruby in 2002, but wtf has that got
to do with anything? If you want to argue through some kind of authority
then you'd better be careful who you try that with and be quite sure you
have some authority.

Secondly, no need to get bitchy because someone questions (not "blasts", no
need to be so touchy) your pet idea. You have to make the case for me to
read the documentation, I'm not going to take my time investigating
something with *no claims or benefits beyond other solutions*. Why not
Pacman? Why not Grunt or npm? Why not take over Bower and bend it to your
wishes? Why not use Puppet or Chef or X, Y or Z??? Make your case beyond "I
know it well". Since you enjoy posting up Hacker News stories, here is one
where plenty of people ask the same questions, and people try to answer in
a reasonable fashion https://news.ycombinator.com/item?id=4821488

> Rubygems worked well for a while. I would say it is broken now.

Rubygems is not broken, it isn't designed to handle library dependencies
beyond a single library and doesn't claim to.

RVM is a Ruby manager, not a package manager.

Bundler is the premier dependency manager for gems. There are others. If
you're having dependency problems and not using Bundler or an alternative,
then use Bundler or an alternative!

So, this becomes a 3 step process:

    curl -sSL https://get.rvm.io | bash -s stable --ruby # run once
    gem install bundler # run once
    bundle install --binstubs --path vendor # once per project

Where's the problem?

> VMs, indeed, do not solve the problem I am referring to.

As far as I can see, a VM is a two step process for the end user. The user
installs VM software and then runs the file you supplied. Job done. I've
done this before for clients when I've had problems installing stuff,
mainly because they're on a Windows box. Works like a charm. I go to
training days where the same thing is done - where is the problem for the
user? The effort is all on the supplier, of course.

Docker also sounds like a good idea, as does Vagrant.

As for version numbers…

> OK. It is not a bad idea, though it is only necessary for package managers
that actually rely on those (which is a rather terrible idea).

If you think defining API changes through a version number is a terrible
idea or only necessary for some package managers, then I would wonder about
anything else you had to say on dependency management.

Regards,
Iain



On 3 May 2014 09:31, Pjotr Prins <pjotr.public14 at thebird.nl> wrote:

> On Fri, May 02, 2014 at 01:16:14AM +0100, Iain Barnett wrote:
> > I don't understand this fascination with GUIX. What does it get me
> > that the other 70 build tools don't have? Each one has its own
> > sweetspot, and none of them have "won" the battle, which suggests
> > this is an incredibly hard problem.
>
> Many initiatives basically confirm people realise we have a problem
> and people try to fix it. Not each project has its sweetspot. Each one
> has its own NIH - and probably came up with a inferior 'solution',
> including rubygems. Rubygems worked well for a while. I would say it
> is broken now.
>
> Tick boxes for a good package manager:
>
> [ ] sane dependency handling
> [ ] transaction based installs
> [ ] unlimited multi-version support (say 8 rubies)
> [ ] binary installs
> [ ] local caching
> [ ] distribution/OS independent
> [ ] both root and $HOME support
> [ ] shared software installs by users
>
> and the main one for me (both as a scientist and system adminstration
> guy)
>
> [ ] guaranteed replication of dependency software tree
>
> You and I can probably think of a few more. You can see rvm solves a
> few of these, but not all. It is pretty rediculous that we have such a
> complex beast for Ruby alone - we would be better off using a decent
> package manager that is shared with, for example, Python.
>
> I agree there is an evolution going on which may end up with multiple
> species of solutions (in addition to the existing ones), some better
> than others. I am happy to ask you pick another one and come up with a
> useful installation procedure. The more we have of those, the more
> likely we end up with a good one.
>
> I choose GUIX because I am acquainted with the deeper internals of
> Nix/GUIX. They have been going for some time now. If you really want
> to know I invite you to read the documentation rather than simply
> blast at other people's ideas. I *will*, however, take the effort to
> reply to real (technical) questions.
>
> You know, other people still blast me today for using either Ruby or
> Linux, and I am still very happy I made those fundamental choices over
> ten years ago. I really am.
>
> I wrote an article about Nix in 2008:
>
>   http://archive09.linux.com/feature/155922
>
> I wrote an article about Ruby in 2002:
>
>   http://www.linuxjournal.com/article/5915
>
> I bet you weren't using Ruby then. I predict GUIX is going to be good
> for us, feel free to *prove* me different. FOSS is about evolution.
>
> > Most of all, until everyone on this list moves to
> > http://semver.org/ for versioning, this is a moot point for me
> > anyway. There's no point talking about build tools until you've
> > fixed your version numbers.
>
> OK. It is not a bad idea, though it is only necessary for package
> managers that actually rely on those (which is a rather terrible
> idea).
>
> Pj.
>
> PS I think we should move this discussion to the SciRuby list. There
> are some receptive people there.
>
>