I highly recommend installing direnv (https://direnv.net/, available in homebrew) instead of using the dotenv gem and .env files. I've seen the sort of confusion you have had /repeatedly/ over the years with dotenv as it doesn't actually provide an environment at all, it's mis-named. direnv actually provides a first-class environment to your application so any command you run is in that env from program start:
will@lentil ~/www/oas/master (on 1e5da09)% cat .envrc export REDIS_URL=redis://localhost:6379 export OBJC_DISABLE_INITIALIZE_FORK_SAFETY=YES export RUBYOPT=-w # Temporary for segfault https://github.com/ged/ruby-pg/issues/538 export PGGSSENCMODE="disable" will@lentil ~/www/oas/master (on 1e5da09)% env | grep RUBYOPT RUBYOPT=-w > On 25 Jan 2024, at 17:36, 'Rob Whittaker' via North West Ruby User Group > (NWRUG) <nwrug-members@googlegroups.com> wrote: > > Thank you both for your comments. > > Much of what Lee said went over my head and made me realise how little I know > about Puma. I have always accepted that it's the tool to use since it gained > popularity. Some stuff went in, but now I want to learn more. > > After Tekin's comments about rails s, I did some more investigating and was > wrong. Running rails s produces no warnings. Running bundle exec puma as per > the Procfile gives warnings, though. > > Puma loads the config/puma.rb file by default. I combed through that file and > commented out lines until the warnings disappeared. The offending line has > something to do with workers. If I set the value to zero, then the warnings > disappear. > > I set the number of workers from environment variables. When we have no value > set, it defaults to two workers. I have this value set to zero in my .env > file. I thought it might be that I was using 0, and the environment saw this > as no value set. I tried setting it to "0", but still no dice. It was time > for a trusty raise. No matter what value I put in .env, there was nothing in > my error. Weird. > > Then, I found this question on Stack Overflow. It makes sense that we load > dotenv after Puma. The gem is part of the Rails stack, after all. What could > I do? > > My next step was to create a separate Procfile.dev with the following line > and a bin/dev wrapper. > > > web: WEB_CONCURRENCY=0 bundle exec puma -p $PORT -C ./config/puma.rb > > > This approach seems like it could be better. I'll have to duplicate the > commands between my two files and now use bin/dev to start my server. With > the extra information I've provided, can anybody give a better solution? -- You received this message because you are subscribed to the Google Groups "North West Ruby User Group (NWRUG)" group. To unsubscribe from this group and stop receiving emails from it, send an email to nwrug-members+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/nwrug-members/52EC2A42-D20F-4AD7-A64B-E3FBBA52440D%40willj.net.
