[BioRuby] Ruby installation

[Pjotr Prins]

Hi Iain,

I am sure you are a great Ruby coder with great ideas, but apparently
they do not align with mine. We are free to disagree. It is a free
world (arguably).

>From here on you can write to me personally if have any real technical
questions.  But, since you appear to specifically question my
authority and/or real knowledge on package managers, I expect there is
no answer from me that will make you happy :) So, let's leave it at
that. Time will tell. 

Pj.

On Sat, May 03, 2014 at 01:33:13PM +0100, Iain Barnett wrote:
> 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.
> 
> 
>