On Thu, Jun 6, 2019, at 10:35 AM, Marco Aurélio Deleu wrote: > Hi everyone, > > I was wondering if there ever was or if there is interest in defining a > standard for configurations / settings that would mostly benefit > package deveiclopers. A few months ago Laravel 5.8 broke a lot of > packages by changing how .env files are handled, which led to this > really good article on the subject: > https://mattallan.me/posts/how-php-environment-variables-actually-work/ > A TL;DR is that _ENV and _SERVER are not reliable as they can be > disabled and getenv is not thread-safe. > There are several packages that provide behavior change or even require > certain configuration to work that use the getenv. If perhaps there was > a standard that packages could rely on to get these values, they could > avoid the quirks of environment variables in PHP. > The Container PSR comes to mind, but that usually involves consumers > being required to have a Container PSR implemented, which involves a > lot more than just retrieving primitive values. It's also lacking a PSR > that defines a standard on how to write to the container. > For these reasons, I was thinking that a PSR focused only on setting / > getting primitive values similar to how environment variables are being > used now would be somewhat a powerful, yet simple standard. It could be > trivial to implement while pushing the problem of handling environment > variables into the application developers and out of the packages. At > the end, application developers are usually deciding the environment > they will run their code and can make decisions based on their needs > while package developers are writing code that will be running on all > sorts of environments and as such should try to maximize their reach.
Disclaimer: I work for a web hosting company that provides service credentials and various other information via environment variables. We also recently released some abstraction libraries for said environment variables in multiple languages. Nearly any application then needs some sort of glue code to map from our env vars into its own configuration, which could be its own env vars or container parameters or some global array or whatever it does. That said, I am speaking for myself and not on behalf of my employer. I am not sure I agree that environment variables are something to avoid. I have read arguments that they are sub-optimal, but the only alternative I've seen is "env vars, but encrypted". That said, I have considered in the past a spec on standardizing the environment variables. Even something simple like how Symfony and Laravel both have env vars for the primary database, but they use two entirely different formats and structures (neither of which is what Platform.sh outputs by default). Or even something as simple as the secret hash key, which should be just a single value string but... no standards. >From a host POV, a standard way to expose common information to applications >would be great. Even if it's language-specific so we are just offering a >common bridge library, that would be better than the status quo. The >difficulty is that it will get out of the "easy" realm above very quickly. So I'd be in favor in general, but we'd need to get the major framworks/applications on board as well as a couple of hosts to make it worthwhile. I'm pretty sure I can get Platform.sh on board, if for no other reason than I'd be the one writing the unified bridge code on our end. :-) --Larry Garfield -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/536c73b6-b4cf-4d5b-8b9d-e012c26bc2d1%40www.fastmail.com. For more options, visit https://groups.google.com/d/optout.
