0

I'm looking at very popular php package named .env here, on packagist and github from vlucas.

My question - why is it better than storing variables in *.ini files?

I mean parse_ini_file() built in php and no extra package required. Why not using it? Why this package is so popular on packagist.org?

There must be a reason for Laravel to use it.

Yevgeniy Afanasyev
  • 37,872
  • 26
  • 173
  • 191
  • `.env` allows loading the configuration to the system environment. Straight loading of `ini` files does not do this – Valdeir Psr Feb 05 '18 at 02:58
  • oh, it must not be a case. you can solve it with one line like `$_SERVER['ini'] = parse_ini_file(...);` To initiate the class you would need more like so `$dotenv = new Dotenv\Dotenv(__DIR__); $dotenv->load();` – Yevgeniy Afanasyev Feb 05 '18 at 03:02
  • There is no definitive reason, it all comes down to picking a convention. It could be a dotfile, a yaml file, an ini file... In the end it's all the same. –  Feb 05 '18 at 03:53
  • In short, you can have more control and features over vanilla `parse_ini_file`. Just as why they have `Collection` in place to supercharge vanilla `array`. – Lionel Chan Feb 05 '18 at 03:57
  • Can you please give me one example or feature that is giving more control? Thanks. PS even `laravel` guys are using wrapper around it to have more control over it. So it is not that good in it's raw form. – Yevgeniy Afanasyev Feb 05 '18 at 04:05
  • As per my answer below, I bet Laravel would not want to reinventing the wheel so included the project as a simple solution getting `env` configurations. – Lionel Chan Feb 05 '18 at 06:12

1 Answers1

2

On top of the duplicated question with no favourable answer, I think (my personal opinion), one particular reason why they opt to Dotenv is that it loads .env and automagically mix your settings with your global $_ENV, $_SERVER and getenv() directly. Then you can access these variables by just using one interface (env() or getenv()). Of course Laravel could have opted to parse_ini_file and reinventing the wheel, but I see no reason for doing it when Dotenv has done it well.

Lionel Chan
  • 7,894
  • 5
  • 40
  • 69
  • Yes we can access env variables in many ways, but it is not a benefit. It is better to use unified way to access these variables throughout the project any way. However, laravel is used for many projects and opting for flexibility is understandable for them. Thank you. – Yevgeniy Afanasyev Feb 05 '18 at 06:23
  • Thanks. I voted up, as it is a good point, but only for laravel, thus, I hope there would be other answers. – Yevgeniy Afanasyev Feb 05 '18 at 06:25
  • 1
    Yea.. I see no particular reason other than an easy mix with _ENV. See what Matt say when he included it: https://mattstauffer.com/blog/laravel-5.0-environment-detection-and-environment-variables/ – Lionel Chan Feb 05 '18 at 06:30
  • Lionel Chan, I did not find any reasoning using your link. But it was fun reading. Thank you. – Yevgeniy Afanasyev Feb 06 '18 at 03:06
  • 1
    Yes he never mention why, but at least he shed some light that they included it because, hmm, it's well established. – Lionel Chan Feb 06 '18 at 05:49