Update
Forgive my ignorance, I think I asked him about rvm when I really meant RubyGems. And I think he's thinking of RubyGems because there does seem to be some controversy over it, at least there was in the past: http://stakeventures.com/articles/2008/12/04/rubygem-is-from-mars-aptget-is-from-venus. So please s/rvm/RubyGems/g for the below question.
End update
My server admin is a little wary of using rvm on Debian. Here's what he says:
Unfortunately, the whole rvm system doesn't interact properly with a
packaging system like Debian, and it's a nightmare to deploy when you
do the deployment at different times. [You can easily end up with
different versions of modules on different systems, etc, and you have
to deal with rvm stomping all over the Debian packaging system.]
I think what he's saying here is that we are going to be running the app across multiple servers and if we upgrade one server, it's going to cause serious problems for us.
Is there a way to address his concerns?
RVM in no way shape or form 'stomps' on the debian package system. RVM installs either in $HOME/.rvm for a general user, or in /usr/local/rvm using the 'rvm' group to which members must be added which is the normal place for 3rd party non-mission-critical applications, headers, and libraries.
RVM came into existence because of package managers. They were forever screwing up dependencies of rubies and gems, being behind the times for getting security updates pushed out immediately, for multiple rubies to be installed and managed on the same box without having to play symlink games to get them to work, and made deployments to multiple machines with multiple disparate deployment requirements a nightmare.
RVM solved all of that in a more than fairly seamless matter, with a specific eye on ensuring not only security of the install, and the users that use it, but also to ensuring that the package manager was in no way involved. This ensures that the package management tools and their databases of installed packages wouldn't get suddenly wacked.
I got involved as a user, and then as a developer on the RVM Project because it solved the dilemma so well and so elegantly.
Rubygems does not allows good control of gem versions, but together with bundler it allows a lot better control of version compared to apt-get.
You need to read on Bundler - it allows you to specify loose dependencies in Gemfile and strict ones are recorded in Gemfile.lock.
His concerns are that ruby is a moving target, ruby is updated every few months and all users should always update to latest patch level.
Ruby is a lot different packages (maybe except openssl), where ruby team is updating releases with patches, this allows focusing security efforts in one place, but this is against conservative approach of package managers where a version is picked and only security patches are applied to it, as stable it sounds - it spreads security effort on multiple teams and slows down whole open source community. Operating system maintainers do not want to accept the fact someone does part of the work for them and they could trust someone with it.
As for the repetitiveness of the process your admin is showing a lot of ignorance, RVM allows to lock versions, which is against the the Ruby approach explained above. So the simplest way to lock everything is to lock RVM to one version:
rvm install 1.15.14
But if the locking of RVM is required the preferred way is to lock it to minor version where compatibility is kept, but updates are provided:
rvm install latest-1.15
RVM does not keep this versions going for a very long time, but anytime there are concerns about current stable "stability" - we keep the previous version updated so you can decide which one to use.
#deryldoucette also explained a lot in his answer, I tried to not "reexplain" things.
Related
Full disclosure. I do not use Ruby. I never have even looked into learning it as a language.
We use ruby at our company to power an integration between a couple of our tools. Due to a TLS update we have to update our ruby version from 1.9.2 to the newest version.
On this windows server 2008 r2 machine I have that version of ruby and need to update. The problem is this tool is in constant use. So I cannot reasonably take the server down for a whole day while I try to figure out what to do. Initial research shows that these older versions of ruby are problematic to update.
I have only a half dozen gems to worry about (and found a really good guide on updating those - I think).
Looking for a kind soul who is willing to help a lost soul.
Is this a case of needing to completely uninstall and if so does that mean uninstall my gems as well? Or can I just run an update via cmd?
This is mostly going to come down to your gem dependencies.
As for just the language, the odds of encountering anything that works with Ruby 1.9.3, but not Ruby 2.0+ will be highly unlikely. Plenty of features have been added, but on a whole, backwards compatibility has been maintained.
This is not necessarily the case with gems, as the dependencies and robustness of the code can vary wildly depending on the source. The only real way to answer anything with confidence is to check/compare dependencies of each gem you require with your target Ruby version. Typically increasing the Ruby version is less likely to "break" anything than lowering it obviously, but it is still a significantly plausible scenario you must be wary of and prepare against.
The only real way to do this without downtime is to clone or setup a new environment for testing, install the newer Ruby, install the required gems you have researched dependencies, and test to make sure everything runs/works as expected.
Unfortunately there is no "magic bullet" here that is going to solve this issue for you. Luckily, the vast majority of this does not require knowledge of Ruby syntax and coding, and if everything goes well, will require nothing more than installing Ruby, installing gems, and comparing versions. If you run into issues with specific gems, I am confident that there is a host of people here on SO that can help guide you through reconciling it.
I am using Rubymine 5.4.3.2.1 with Ruby 1.9.3 under Windows 8. Debugging even the simplest programs is impossible because at the breakpoint variable display, drilling down on any complex variable ends up in an unending "collecting data" response. Debugging is useless.
I've been working with JetBrains for 2 days to solve this. They cannot recreate it. However, I have seen a number of posts where other users have had this problem and migrated to other debuggers. I'd rather stay on Rubymine if I can fix this. But, I need to use the debugger.
JetBrains has had me dump them varied information, disable the firewall, give them sample code, show them screencasts, reinstall gems and provide them a thread dump which they will look at next week. They asked me to try it on another workstation, which I don't have, and upgrade to Ruby 2.0, which wouldn't help since the code I'm using isn't compatible. I have searched (and searched and searched) for an answer. I have reinstalled Rubymine. All, to no avail.
Is anyone else seeing this problem? Has anyone else resolved this problem? Do you have any recommendations for me?
If someone else is seeing it, please report it to JetBrains.
Upgrading to current Ruby, such as 1.9.3p448, fixes this.
It turns out that BitNami has made a recent change in Rubystack that downgraded Ruby while applying the TCS (The Code Source) performance patches as of their Rubystack version 1.9.3-8. They provide inadequate notice or explanation of what they did or why. They did this only for Windows which makes no sense because that is a development environment. As of this date, Rubystack 1.9..3-12 is being distributed with this change that downgrades Ruby to 1.9.3p231.
BitNami Rubystack users that upgrade may see a rash of problems. If they choose to do so, they need to make sure they reference the TCS Ruby source code for builds. BitNami does have a recommendation regarding how to upgrade to current Rubyinstaller versions, which is a relief. You can see this at:
What Ruby source matches Rubystack 1.9.3-12?
My fix is going to be to download the RubyInstaller 7zip files and change the content of the BitNami Ruby folder for this other one as referenced here:
Is the Rubystack version outdated in release 1.9.3-12?
I'm on OSX, 10.8.3, ad use homebrew. I was wondering it would be possible to have multiple instances installed. I have the default /usr/local/ install but would like to have a completely separate version where I can test packages and different installs without screwing up my basic install in /usr/local/ that works great.
I read the wiki and all that about installing into ~/(.)homebrew and then symlinking "brew" to /usr/local/ but I imagine that would conflict with my current install in that directory.
I do not mind, and realize I will have to change my projects to work with the different homebrew path but if anybody has done this and has some suggestions I would greatly appreciate it.
There is still no great way to clean dependencies for formulas well, imo, although progress has definitely been made. I know it's not recommended but I would like to have a "test" homebrew install where I can install all kinds of temporary packages needed for just one or two quick tasks and remove. I appreciate ANY and ALL advice so if you have anything that might be helpful, please do let me know.
Cheers and thank you SO community!
I'd recommend using a virtual machine as a testbed, instead of an alternate homebrew installation path. A VM setup has several advantages:
Homebrew can still live in its preferred, supported path.
You can see exactly what your formula changes will do to a "normal" installation.
You can still use broken, non-relocatable formulae safely.
Files are guaranteed not to leak out of your alternate path and clobber the main Homebrew install or other stuff, like they can if you have errors in your formulas
You can use VM snapshots to provide a clean baseline, and revert to them to discard any changes or mistakes.
You can make a bunch of alternate setups instead of just one or two, and they're all independent.
You can have a minimal install to isolate variables and reduce interactions.
You can even run them with other OS versions.
You can mess around with scary low-level stuff like kernel extensions without fear.
You can hand off an entire machine to a collaborator so they can se exactly what context your testing stuff in.
It's good practice for learning how to automate and modularize machine setup and configuration and will make your code & deployment process better.
Etc etc
I use VMs for all my Homebrew development work and it's great. I will never be doing deployment-oriented work without VMs again. Parallels is good, totally worth the money IMHO, or you can pick up VirtualBox for free.
To get your development code between instances, you can use git or other version control to shuffle them around, or mount virtual shared drives, or both.
RVM is great for developing on your local machine. But is it safe on a production machine?
I built RVM for production and added the developer 'niceties' later on.
If you would like more information read the documentation on the website and come talk to me in #rvm on irc.freenode.net sometime during the day EDT most days.
Since RVM is just a fancy way of downloading, isolating and switching between existing Ruby implementations, I'd say that it's as production ready as whatever ruby implementation you're currently running it with.
Essentially, all RVM does is point your path at a specific Ruby implementation. This is exactly what happens when you use your *nix distribution's Ruby implementation. The only real difference is that your path will be re-written so that when you run ruby -v it will run a ruby from your current user's .rvm directory instead of a global system directory like /usr/local/bin.
I'd go even further and say that using RVM is a better solution than using what generally gets installed in a *nix distro because it makes it easy to sandbox the specific ruby implementation on a per-user basis. RVM also makes it possible to attempt switching rubies (ie; from 1.8.7 to 1.9.2) on your production app while keeping a solid rollback strategy in place if something doesn't work quite right. It also makes it easier to keep old applications running on one version of Ruby, while switching new apps to more current versions.
I disagree, especially if you're using any kind of automated production process (puppet, chef, fog, etc) and you have more than one or two machines.
We've had issues where version X of RVM worked in a completely different way to version Y of RVM (different default Rubygems versions, different default gemset configs, complete changeup of how system wide install works), breaking our automated provisioning process.
Not an issue if you're developing and on hand to tune things, a killer if you have an unattended scripted / puppet install. We worked around these issues by locking to a particular RVM version, but I remember having a conversation with Wayne where he discouraged this. If we kept using RVM in prod, we were going to actually package it into a series of .debs (one for the install, one for each Ruby).
The way that .rvmrc prompts by default and can only be overriden in the homedir ~/.rvmrc (and not the system-wide one) was also unhelpful.
I actually like the way that RVM will change up and do things this way in development - nothing sucks more than being held back by backward compatibility. This approach, however, cost us some time (and pulled hairs) in production/staging/uat/test.
RVM is apparently a reasonable production tool
You know, I once made a similar rvm is a development tool comment and was informed that rvm was originally a production tool.
So, RVM will make your production environment more complex, which is bad, but it makes it more isolated and compartmentalized, what the language people would call modular, and that's good.
In the end, as long as you test your deployments, I don't see how a static configuration of any kind could be, all by itself, "unsafe".
It all depends on how you are installing RVM , single-user or multi-user . installing RVM system wide can cause lots of mess whole switching between different rubies. Better you opt for single user , minus that RVM does a good job for what it's meant to do .
I guess there's two parts to this question:
Is RVM intended to be for production machines, as opposed to development machines?
Is RVM reliable enough software to be used on production machines?
For (1), Wayne E. Seguin has stated that it's intended to be used on production machines. There's no point in disputing his intent.
For (2), I'm not so sure. Is it appropriate to use software that has a new version number every couple of days on a production machine? Also, RVM once deleted my entire ~/ruby directory. To Wayne's credit, when I told him about it, he fixed it that night, but that doesn't exactly say "production ready" to me.
Edit: I've just read about bumblebee's deletion of /usr, and I'll just say - it could have been worse! LOL.
I've been using RVM on a production webserver for over a year now with zero problems. I've kept it pretty up-to-date, running rvm get head frequently. Zero issues, ever. :)
Yes, I've used rvm on production machines and also set up puppet modules to install rvm as the default system ruby along with gemsets, etc.
If you run multiple apps on a single server, rvm can help you keep all your apps gemsets (and ruby versions) totally separate. However, if you are running only a single app on a server, there may not be as much benefit to having rvm installed.
I've pretty much used RVM on all my production servers running rails apps!. RVM has not let me down.
Last year, in 2009 GSoC, I participated with an organization called Winlibre. The basic idea is having a project similar to Aptitude (or Apt-get) and a GUI like Synaptic but for Windows and just to hold (initially), only open source software. The project was just ok, we finished what we considered was a good starting point but unfortunately, due to different occupations of the developers, the project has been idle almost since GSoC finished. Now, I have some energy, time and interest to try to continue this development. The project was divided in 3 parts: A repository server (which i worked on, and which was going to store and serve packages and files), a package creator for developers, and the main app, which is apt-get and its GUI.
I have been thinking about the project, and the first question that came to my mind is.. actually is this project useful for developers and Windows users? Keep in mind that the idea is to solve dependencies problems, and install packages "cleanly". I'm not a Windows developer and just a casual user, so i really don't have a lot of experience on how things are handled there, but as far as I have seen, all installers handle those dependencies. Will windows developers be willing to switch from installers to a packages way of handling installations of Open source Software? Or it's just ok to create packages for already existing installers?
The packages concept is basically the same as .deb or .rpm files.
I still have some other questions, but basically i would like to make sure that it's useful in someway to users and Windows developers, and if developers would find this project interesting. If you have any questions, feedback, suggestions or criticisms, please don't hesitate posting them.
Thanks!!
be sure to research previous efforts on this. Google turns up several similar/relevant efforts.
http://en.wikipedia.org/wiki/Package_management_system#Microsoft_Windows
http://windows-get.sourceforge.net
http://pina.plasmite.com
IIRC there was an rpm for windows at some point
Also I think there was some guy (who used to work at MS) in the news recently that basically is starting up a very similar project. I can't find a link to this now.
But anyway, yeah, it would be awesome if there was such a standard tool and repository.
I can only speak for myself, but obviously I could definitely make use of such a tool as I found your post through googling! ;)
My two use cases for this tool would the following ones:
1. I generally avoid to re-install my system as long as possible (in fact I manage to do so only for switching to a reasonable (not each an every) new version of Windows every few years or to setup new computers). But still I'd like my software to be up-to-date. Neither do I want to have to go to all the web pages and check manually if there are compatibility issues with the new version of Doxygen, Graphviz and the latest version of MikTeX for example, nor do I want to have to navigate to the download pages and run the setups all by myself. I just want to schedule ONE SINGLE (!) tool, which checks whether there are new updates or not and updates those applications which are not in conflict with any other application version.
If it unavoidably happens to me that I have to re-install my system, I don't want to get the new setups neither (and check compatibility). I even don't want to wait for one setup to finish in order to start the next one, I just want to check the tools I need, or even better, I want to simply load my "WinApt XML" batch installation file, which gets the installers and handles the setups sequentially all by itself.
I don't know enough about the architecture of .deb or .rpm but IMHO the most reasonable would be to maintain a DB with only the names, versions, dependencies and the location of the different versions' download locations. I mean, most of the tools available for Windows provide .msi packages anyways, which (I guess) is the application itself and some custom installation properties (really not sure how scripting is handled, but I know that creating a MSI in Visual Studio has very limited abilities to create custom installation steps and I can only imagine this is due to limitations of MSI protocol).
I guess a GUI will be mandatory for Windows users ;) but I personally would prefer the additional ability to handle the setups with the console.
Well, I like the idea and would love to hear from that (or such a) tool in the future.
Cheers
Check out NSIS. It's an open source MSI creator. You might be able to use it as part of your package creation software.
http://nsis.sourceforge.net/Main_Page
For the ALT-.Net tool/lib stack there have been some affords in this direction: Horn Get
However, the usability in a real world project has been subject in this SO question.