It may be the Baader-Meinhof effect, but I've seen more mentions of direnv over the last day than I have ever before. I've added a card to my backlog to investigate swapping out dotenv.
Thank you all for all your help. You've pointed me in the right direction. If any of you wanted to give a talk at NWRUG about Puma I would love it. If you wanted to explain Puma to me, I would love to give that talk to aid my learning. On Friday, January 26, 2024 at 10:36:32 AM UTC Lee Hambley wrote: > +10 to what Will said. Using a _Gem_ to load env config is a pretty big > violation of the "outside in" principal of environment variables. In > principal environment variables are mapped into a processes memory space. > > From Wikipedia: > > In all Unix <https://en.wikipedia.org/wiki/Unix> and Unix-like >> <https://en.wikipedia.org/wiki/Unix-like> systems, as well as on >> Windows, each process has its own separate set of environment variables >> <https://en.wikipedia.org/wiki/Variable_(programming)>. By default, when >> a process is created, it inherits a duplicate run-time environment >> <https://en.wikipedia.org/wiki/Run-time_environment> of its parent >> process, except for explicit changes made by the parent when it creates the >> child. At the API >> <https://en.wikipedia.org/wiki/Application_programming_interface> level, >> these changes must be done between running fork and exec. Alternatively, >> from command shells <https://en.wikipedia.org/wiki/Command_shell> such >> as bash <https://en.wikipedia.org/wiki/Bash_(Unix_shell)>, a user can >> change environment variables for a particular command invocation by >> indirectly invoking it via env <https://en.wikipedia.org/wiki/Env> or >> using the ENVIRONMENT_VARIABLE=VALUE <command> notation. A running >> program can access the values of environment variables for configuration >> purposes. >> -- https://en.wikipedia.org/wiki/Environment_variable > > > In theory if you argue that you load env vars before the fork on a > preforking webserver, maybe it's _not_ breaking core principles of > unix-like OSs but it's really bad practice for a process to read it's own > "env vars" (it can load config files all day long, but env config is a > specific thing with specific semantics) > > Lee Hambley > http://lee.hambley.name/ > +49 (0) 170 298 5667 <+49%20170%202985667> > > On Fri, 26 Jan 2024 at 10:41, 'Rob Whittaker' via North West Ruby User > Group (NWRUG) <nwrug-...@googlegroups.com> wrote: > >> You make some excellent points, Will. Your approach is something I will >> consider over the longer term. I plan to pinch these lines from Rails' >> default Puma config >> <https://github.com/rails/rails/blob/68eade83c87ae309191add6dfa4959d7d7e07464/railties/lib/rails/generators/rails/app/templates/config/puma.rb.tt#L28-L41>. >> >> People more intelligent than me have already solved the problem. >> >> On Thursday, January 25, 2024 at 5:45:55 PM UTC wi...@willj.net wrote: >> >>> 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-...@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-member...@googlegroups.com. >> > To view this discussion on the web, visit >> https://groups.google.com/d/msgid/nwrug-members/32bb2225-1a24-43ca-803b-52173fe2649fn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/nwrug-members/32bb2225-1a24-43ca-803b-52173fe2649fn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/626575d8-505f-488a-b25a-7a0dfc652102n%40googlegroups.com.
