Issue was closed with “this is not a rails problem” but a puma problem. Which makes sense, to some degree. I think I have the experience to workaround the issue for me, but I think it is against the bigger picture for rails appealing to developers and increasing productivity. This machine is a standard mac os, m1, rvm, ruby-3.0.4. Nothing special and yet “rails new project” does not work.
Through the years I’ve seen many instances where people find it difficult to get rails up and going. We all know that once you do, you could get up to speed really fast. But getting it, might be difficult.
I don’t know what the solution is here. Probably puma is not needed for “rails new project”, or probably another, more stable version of puma should be required - one that could be installed on a “rather standard” machine as this.
Let me know your thoughts.
current directory: /Users/kireto/.rvm/gems/ruby-3.0.4/gems/puma-6.4.0/ext/puma_http11
make DESTDIR\= clean
current directory: /Users/kireto/.rvm/gems/ruby-3.0.4/gems/puma-6.4.0/ext/puma_http11
make DESTDIR\=
compiling http11_parser.c
compiling mini_ssl.c
compiling puma_http11.c
linking shared-object puma/puma_http11.bundle
Undefined symbols for architecture arm64:
"_SSL_get1_peer_certificate", referenced from:
_engine_peercert in mini_ssl.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [puma_http11.bundle] Error 1
make failed, exit code 2
Gem files will remain installed in /Users/kireto/.rvm/gems/ruby-3.0.4/gems/puma-6.4.0 for inspection.
Results logged to /Users/kireto/.rvm/gems/ruby-3.0.4/extensions/arm64-darwin-21/3.0.0/puma-6.4.0/gem_make.out
You said your system is “nothing special” and “standard mac os m1, rvm, ruby-3.0.4”. But the reality is, where there is seemly nothing special there is actually a huge amount of variation. For example, I also have a Mac m1 on my work computer, but OTOH I’m using asdf instead of rvm and a different ruby version. I.E. while it’s similar to your setup it’s not the same. And the next developer is different from both of our setups, even if similar.
I’ve never encountered that puma issue you hit on my “standard system”. Taking a quick look at the issue it seems to relate to multiple installations of OpenSSL and puma not using the right one. I guess my “standard system” has only a single version of OpenSSL installed while yours has multiple. Another difference.
My general point is it’s a game of wack-a-mole that will never be solved because of the huge variation. There is no “standard system”. If not this puma issue, then some other issue maybe in some other library because of some small difference between systems. All we can do is keep wacking the moles as fast as we can which the puma folks seem to have already even done before you hit the issue and it just hasn’t made it out the door yet.
You mentioned in the Github issue, your concern if for folks new to Rails or programming driving them away. I sort of have two opposite views on that:
Hitting issues like this, digging in and resolving them is basically the job. If that process is too discouraging they may not like the job. I spend a lot of time working through little annoyances exactly like this. So it may just be a good opportunity to show students this aspect of the job and that can help inform them if this is a career they want to get into.
I do understand if you get discouragement early it may turn you off from a subject so it’s important to have some early success to get you addicted before you encounter the struggles with a profession. Therefore if you want to avoid these types of issues then you really want a “standard” system even more than you think you have to help ensure these sorts of issues don’t pop up. And the most packaged version of a standard system I know for developing Rails would be the docked CLI. Regardless of what OpenSSL libraries are on their system (or whatever other oddities might pop up) docked should allow them to develop Rails applications in about as standard of an environment as you can have. Then once they are addicted to hacking Rails they can move to a more full development environment of not working in a container.
Gems that depends on SSL have this kind of problem, sometimes. Maybe there are some dependencies missing in your environment. A good tip to isolate the problem is to try to install the problematic gem directly.
So, try this first:
rvm use ruby-3.0.4
gem install puma -v 6.4.0
The above gem install is expected to fail. But now you can focus on this specific error before try to create a new Rails project again.
As @masterleep suggested, you should be able to install the gem passing this compilation parameter PUMA_DISABLE_SSL=1.