Threads for daniel_kehoe
-
Because some Gems have become unfathomably broken and starting from a clean slate is the only thing that seems to work. I’d say I’ve had to do it a good 5 times.
-
Ah, that may be one reason people are trying to uninstall Ruby.
-
-
if you update your system beyond what the native C extensions to the gem that were compiled to the system expect you have to rebuild the gems again… that’s a very common thing in ruby and not really the fault of ruby at all. the price of admission to have native extensions. I expect python to have a similar issue. ruby probably needs to be reinstalled too come to think of it since that’s built expecting some native libraries to be there.
-
-
A guess; to get rid of the conflicting system ruby?
-
It looks like the article explicitly tells you not to uninstall system Ruby and discusses only how to install Ruby from other places. My guess, from limited interaction with Ruby beyond the pain of conflicting versions of Ruby packages, is that it’s increasingly seen as a bad idea to have a global version of things like Ruby and Python installed and instead to have separate locally installed trees.
It’s interesting that most of the traction that Go is making relative to Python comes from having exactly this model: you install packages for dependencies only in your build directory, not anywhere globally, and the thing that you ship is a statically linked binary. There’s a weird conflict in the Python ecosystem between ‘write it in Python, everyone has Python installed out of the box’ and ‘make sure you use pipenv to avoid touching any system-wide packages, and make sure you have exactly this version Python you need installed for that environment’. Both are sensible (it’s great to ship something small and depends on things that are there already and to have a central place to manage security updates, it’s also great if the thing works when you install it), it’s just not possible for both to coexist.
-
That’s a good way to put it.
-
-
I’ve always been told to leave the system Ruby alone, install a version manager, and set a $PATH to use the version manager. Isn’t that good enough?
-
-
I just wrote a guide to installing Ruby on macOS with Frum, the newest Ruby version manager. It’s a great alternative to rbenv, RVM, chruby, or asdf! From the article:
Frum is written in Rust. It is new (released in early 2021). Unlike asdf, chruby, or rbenv, it includes a built-in Ruby installer command so there’s no extra program needed to install Ruby. The installer is fast and Frum requires no dependencies (it’s an all-in-one Rust executable you can install with Homebrew). The Frum version manager is added to your shell to intercept any calls to Ruby. After you install Frum, you must modify your ~/.zshrc file so Frum runs in your local shell environment. Like the other version managers, it checks for a .ruby-version file in a project directory and, if there’s no version specified for a project, it will default to a global Ruby version. There are no shims (unlike Asdf or Rbenv) and it doesn’t override the cd command (unlike RVM).
-
Link goes to Homebrew instructions, Frum instructions are here
-
-
This is a pretty cool idea for a site. I can see how it would be fairly useful as a catch-all for node/python/homebrew/go/eclipse/gcc/etc…
-
Thanks! The blog format of most sites doesn’t suit me for writing guides or tutorials about technology. I prefer in-depth structured articles. Dev.to, Hackernoon, Hashnode have a place but I’m trying to make a better site for “evergreen” long-lasting articles. You’re right, mac.install.guide could be expanded beyond Ruby to other topics. Want to contribute? How can I contact you? I’m daniel@danielkehoe.com via email. Or PM me here.
-
-
So is
rvmno longer fashionable? I’ve used (and contributed to) it for years and never really explored except a brief flirtation withruby-installandchrubythat didn’t go well enough to merit continuing it.-
Do you recall why chruby didn’t work well for you? Would be good to know as I recommend it over rbenv and rvm.
If rvm is working well for you, stick with it, changing may not be worth the effort. After Bundler was added to Ruby, rvm lost favor (with some) as its gemset feature is no longer needed. Rbenv has always had its fans and chruby gained favor among the “smaller is better and more Unix-like” crowd. Right now, asdf seems to be gaining in popularity as it can accommodate multiple languages (Ruby, Node, etc) and that’s useful since the Rails installation got bloated with a requirement for Node as well as Ruby. That’s current fashion, as I see it :-)
-
I’m not sure if it’s completely fair to say that chruby is simpler than rbenv. It looks like they have almost identical user-facing features, the differences between them now just look like implementation differences. (I’d believe that the implementation is simpler though! I haven’t compared myself)
That said, I’m definitely a “rbenv fan” haha. It’s reliable and invisible; I only think about it when starting a project and when upgrading Ruby versions (rbenv handles shims automatically now). One feature of rbenv I find useful is that it supports fish shell out of the box
-
All good points for rbenv. Handling shims automatically was a great step forward. So yes, really just implementation differences at this point.
-
-
I don’t, but it might have been because I was still trying to use gemsets. I don’t remember how long ago this was but a lot of my Ruby projects are old and their env was setup during peak RVM popularity. Since then, there’s an explosion of version managers. I’ve recently moved onto a Python team and am really digging pyenv.
-
I don’t, but it might have been because I was still trying to use gemsets. I don’t remember how long ago this was but a lot of my Ruby projects are old and their env was setup during peak RVM popularity. Since then, there’s an explosion of version managers. I’ve recently moved onto a Python team and am really digging pyenv.
-
-
-
I’m trying to cover all the questions that come up for my Ruby installation guide. This one comes up a lot when people install Ruby with Homebrew (for example, following the Jekyll installation instructions). Let me know if I missed anything or anything’s unclear.
-
-
Thanks for the kind words! You had me worried for a second as I thought maybe I overlooked it. But
asdf global ruby 2.7.0is there under Set Ruby version with asdf on Mac. A bit buried as the article is dense, yea.What were you using before asdf? Been happy with it?
-
-
-
-
This was also covered in How Web Components Are Used at GitHub and Salesforce but the GitHub blog post really goes in depth. Glad to see it. Web components are getting more attention now, maybe since Custom HTML Elements were finally supported last year in all major browsers.
-
This question comes up a lot among Ruby beginners so I wrote an article that goes into detail. I explain why it’s worthwhile to install a version manager. I recommend asdf for those developing Rails web applications (which require Ruby, Node, and Yarn) or those using multiple languages such as Ruby, Node, and Python. For a simpler version manager just for Ruby, I like chruby. The article provides all the details, explanation as well as instructions. Let me know if I missed anything or anything’s unclear. Sharing it here on Lobsters because the community might have suggestions for improvement.
-
I like the idea that the browser becomes a native package manager without Node, NPM, or additional build tools.
“This import map is all that is needed to work with dependencies in native modules workflows in browsers, allowing you to get back to focusing on just running your own code natively in the browser, instead of needing to configure complex build tools and package management systems.” [0]
“Import map management becomes a form of package management in the browser.” [1]
[0] https://jspm.org/docs/cdn [1] https://jspm.org/docs/workflows
-
top-level esm imports, while cool for some reasons, are basically the same problem as the now rarely used CSS imports, the loading waterfall is basically bonkers. The lazily async loading stuff is neat, and perhaps the big win for the future, but I don’t see how we aren’t just repeating the same mistakes we (as web developers) abandoned a decade ago.
As an experiment at $WORK$ I created a target with a full ESM compliant output to remove all code duplication in an effort to reduce total amount of bytes transferred, and the performance was absolutely horrible. The previous “dumb” minified/bundled js took at most 0.4s on a really bad network, was now a minimum 8s as minified ESM targets on a very good network (I didn’t even bother simulating 3G and such) despite being significantly less total data.
Going forward I don’t think we are going to actually see widespread adoption outside of splitting up monstrous react apps, because as it currently stands it’s super user hostile for library loading. It’s better to just bundle everything and provide an esm target, which negates most of the interesting benefits of ESM as far as I’m concerned.
-
-
Posting here to lobste.rs for a check of accuracy. Surprisingly (or not), beginners often ask, “Is Ruby already installed on my Mac?” So trying to answer that and provide a link to an installation guide I’ve written.
-
Ruby has been installed on macs since at least OSX 10.4
It’s probably out of date, and most guides want you to install a newer copy, but it’s always there, and is a good starter ruby, if you just want to play around with the language. If you want a newer copy you can always use rvm or rbenv to install and use a newer version, and not mess with the system installed ruby.
-
-
Didn’t we just get told not to use langs installed by homebrew because other casks use it as a dep and it will be upgraded without notice?
-
-
Link in case anyone missed that story: Homebrew Python Is Not For You
-
Just wanted to say thanks for the link. I’ve updated the advice about installing Ruby with Homebrew.
-
-
-
Part of the argument can be easily circumvented. Have a look at
gem install --userandbundle config set --global path. These allow you to install and manage all your gems in your homedir without the need for sudo. I do this all the time in Linux and OpenBSD to use the system ruby.-
Can I ask, why it it you don’t want to use a Ruby version manager?
-
I see no benefit in using a separate package manager just for ruby when my package manager can do the same without me having to think about installing updates in yet another package manager. I don’t need 3.0 when developing my Rails projects. 2.7 and 2.6 are fine, the server will be running these as well probably.
-
Personally I like to run the same ruby as production, down to the patchlevel. I see no reason not to spend the extra 10 minutes to be sure that part of my environment isn’t hiding a surprise.
-
no reason not to spend the extra 10 minutes to be sure that part of my environment isn’t hiding a surprise
Mere hours of debugging subtle differences in behaviour between interpreter versions in production cash save you entire minutes of setting up the same version in dev! ;)
-
-
-
-
-
Always heard this advice but didn’t know why. So I looked into it. Basically, the system Ruby is fine for running sysadmin scripts (as long as you don’t add gems or try to update it). But don’t use it for development because:
-
the default location for gems is the system Ruby directory
/Library/Ruby/Gems/2.6.0so you will need to be superuser to install gems (and you really shouldn’t alter this folder) -
you could use sudo to install gems but that’s a security risk (gem installation can run malicious code)
-
using Bundler is a best practice to manage gem versions and dependencies
-
it’s best to start projects with the newest version of Ruby and the system Ruby is 2.6.3
-
the pre-installed Ruby is deprecated by Apple and may disappear in future macOS releases
Did I miss anything?
-
the default location for gems is the system Ruby directory /Library/Ruby/Gems/2.6.0 so you will need to be superuser to install gems (and you really shouldn’t alter this folder)
Why not install gems into a user managed folder? Blithely installing non-system things into a system (which could be package-managed) folder seems like a really bad idea.
-
-
Here’s an article that shows how to set up both Rails 3.2 and 4.0 with Ruby 2.0. Uses some new features of rvm. “With both versions on your machine, you’ll explore the new features of Rails 4.0 while continuing to develop projects with the most recent stable version.”
-
The tutorials are not intended to supplant the great introductions to Rails we already have (including Michael Hartl’s book). Rather, they are intended as a next step for developers who are gaining proficiency.
-
-
Yes, good suggestion, thanks!
-
-
-
daniel_kehoe
10 years ago
|
link
| on:
Gallery of the best Open Source Ruby on Rails apps (relaunched)
Very happy to see this site coming back to life.
-
daniel_kehoe
10 years ago
|
link
| on:
Unholy Rails: External Scripts, jQuery Plugins, and Page-Specific JavaScript
Show lobste.rs: My attempt to sort out confusion about the best way to add a JavaScript library to a Rails application. I wrote this in-depth article to explore what to do when your application is not wholly Rails. Comments and discussion welcome.
-
Looks nice, but
License
Kube Framework is absolutely free.
That’s not a license.
-
And it’s not on GitHub. Looks like a nice alternative to Twitter Bootstrap but it’s not going to gain widespread support without some licensing clarity and a GitHub repo.
-
-
It’s unnecessarily ambiguous, but it’s a license. There’s questions about the definition of the word “free” in this context. Is it gratis, or is it libre? It gets even more confusing, in the code it reads “License: free” which raises the question: is the license free or is “free” the name of some license. I think the license on the site takes precedence, implicitly naming it the “free” license. It’s all pretty dumb.
Considering the context is software licenses, a free license is one that grants rights to modify and distribute software in the “libre” sense. The term “absolutely” can be easily shoehorned to pretty much let you get away with murder (in the context of the code).
It’s basically a shitty version of the WTFPL.
-
-
Michael Bleigh’s latest project (with designer Jake Johnson).
Author of the article here. I attempted to sort out the differences among Ruby version managers, including the newer ones. I’m interested in your opinions, experiences, or advice.
TIL about
frum. Currently usingrbenv, I like the idea of not needing to deal withruby-install.I know most site owners don’t care, but, FWIW, a totally blank page is served when cookies are rejected. (And therefore I didn’t read your article even though I was interested in the content based on the subject line.)
Thanks for informing me! This is the first time I’ve published with Sitepoint. This will be a consideration when I think about publishing with them again. I’m happy to email you a copy (and anyone else who doesn’t want Sitepoint cookies). I’m daniel@danielkehoe.com.