-
-
Notifications
You must be signed in to change notification settings - Fork 626
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detect and convert types #104
Comments
We do this don't we? |
We have tests that prove this works. |
Currently it returns |
What version? |
Hmmm. |
The latest dev version (2.1@dev) |
NB, 2.0.x is the latest version. I don't recommend using an unreleased version as it's still subject to change. |
Yes, you're right 😄 2.0.1 does the same. |
@GrahamCampbell These are converted in Laravel, but not in phpdotenv itself. The only reason this is not done in phpdotenv is because I originally tried to keep it as close to shell as possible, and in PHP ENV variables, everything is a string. I am not opposed to adding this functionality in, though - and we can probably even just grab the code from Laravel that does this and put it in phpdotenv. |
Maybe, a way to keep backward compatibility is make this behaviour optional. For example: $dotenv->load(); // do not convert types
$dotenv->load(true); // convert types |
Here's how laravel handle this: https://github.com/laravel/framework/blob/8c614010648bffb8bc24c3b532db08619e9a5983/src/Illuminate/Foundation/helpers.php#L626 |
Yeh, but laravel makes it impossible to have |
Yes, I think this should be handled when loading values, so it's possible to differentiate between |
Well, thinking about this, maybe this is not good idea and it's better the way laravel handles this, using a custom function to consume the environment variables. So if you want to convert the values, use the custom function and if you don't, use var_dump(env('MY_BOOLEAN_VALUE')); // bool(true)
var_dump(getenv('MY_BOOLEAN_VALUE')); // string(4) "true" |
This approach is above the level of phpdotenv, since it does not provide any convenience methods by itself. To me, this is an argument supporting keeping things they way they are. |
Yeh, we probably don't need to change anything tbh. |
I've been wanting something like this, but probably alongside the current |
Same problem #129 |
There is a solution in #121. We need to get this added to the README. |
@vlucas thanks guy, i am happy to help. |
I have to use following solution;
|
Leaving this for people to wrap. |
(since phpdotenv doesnt do it. Ref:vlucas/phpdotenv#104
such constructions will kill php in a meantime filter_var(getenv('APP_DEBUG'), FILTER_VALIDATE_BOOLEAN) Instead of executing the simple command as in a normal language you start to add useless sophistication "very simple" So simple and elegant! Every php line should be like this! Keep up good work!
My comments to this code would be: |
@drmax24 I agree with you. What got me here is because of this problem. Actually I must say I do not quite agree on automated conversions inside dotenv file. I use Laravel, and including phinx for the independent library for database migrations. There is a problem caused indirectly because of this mindset. |
Environment variables really don't work quite the same way as most typical languages when it comes to booleans, since they don't really exist in the traditional sense. Personally, I'd shoot for broader compatibility and just embrace how environment variables work. An elegant way to do this that "just works" even if you're not using
... then... if ((int) getenv('MY_VAR')) {
// ... won't run.
} else {
// ... always runs.
} In every scenario above, |
So where did we land on this. If this isn't going to be a planned feature can we at least update README to explicitly say that booleans must be handled in user code. |
https://www.php.net/manual/en/function.getenv.php has return type |
@GrahamCampbell do you happen to know where the env function ended up in Laravel 8+ ? Are you open to changing the language on README that talks about getenv and if the user even cares about running php with thread safety (mod Apache). Maybe a link to a SO that explains thread safety etc, would probably help a lot of people. |
Yes, the env function source code is: https://github.com/laravel/framework/blob/8.x/src/Illuminate/Support/Env.php. |
@GrahamCampbell Thanks for the link! Any thoughts on the other question? Happy to take a crack at clearing up the Readme. I don't want to waste time unless you are open to it. |
And this issue is closed, because? EDIT: Sorry, I missed @GrahamCampbell's comment about the return type of |
vlucas sounded like he was not opposed to (at least optionally) replicating Laravel return types but Graham most definitely is. I tried pushing for updated Readme to at least explain their reasoning and hopefully remind people coming back to this library that it doesn't work how you are probably expecting. |
Environment variables are strings. The type of an environment variable repository is |
… default assign them boolean values. So to remedy this, let's refrain from using any typical boolean values. Reference: vlucas/phpdotenv#104
You can just use $active = $_ENV['SOME_CONFIG'] == 'true'; |
But you shouldn’t, that’d be crossing concerns and gets confusing. Just treat environment variables as strings 100% of the time, because that’s what they are. If you need a number or need a quick way to interpret an environment variable as a Boolean, the simplest thing to do is just type cast it to |
Can someone explain to me why something as simple as the absence of quotations couldn't be used to indicate a non-string data type? I believe this, along with the ability to specify default values, would be a welcome improvement.
|
If you read the thread above, several of us give the explanation for this: Environment variables are strings. Environment variables can come from several sources, not just But that’s just my opinion on why this is probably not being done. 😊 |
That said… I could see For example, it could logically interpret |
In my
.env
file I have values like:But the type of these values is always string:
I think the values like
true
,false
,null
(or even numbers), without quotes, should be converted to the correct type (boolean, integers, etc), because in cases like this,APP_DEV
returns"false"
so it's evaluated astrue
:The text was updated successfully, but these errors were encountered: