Values of env variables wrong after update/add operations about capistrano-dotenv-tasks HOT 7 CLOSED

Hi @cassioscabral,

Actually the fix seems a bit more complex to me.

The script works by unserializing the config into a hash to manipulate it. When the manipulation is complete, the hash is serizalized back and it totally replaces your original .env file.

What would you expect it to do ideally, considering that a mix of quoted and unquoted variables depending on some configuration or previous state might be considered, but I'd appreciate some alternative solution.

Can I ask you why the quoting is a problem for you ? It seemed to me that dotenv only parses strings, but I might be wrong !

from capistrano-dotenv-tasks.

Simply putting, when I went back to my old .env without the quotes it worked.

CONFIGURATIONS = {
default: {
key: ENV['KEY']
}
}

this was inside a custom class under the lib folder. I know the value was retrieved. My guess would be the gem that this class communicates with, might be parsing something wrong. It does seems odd, but my worries are more about the gem and the .env itself. If all my values doesn't contain quotes it should remain that way. That's why I opened the issue. Like I said, I don't have enough time to look into that this week or next. But I will look more into it as soon as possible.

from capistrano-dotenv-tasks.

If all my values doesn't contain quotes it should remain that way

I understand that this is something you'd want.
But before starting to work on that solution, I'd like to understand better your concerns.

For me, the solution would imply to add some kind of "quoted" flag to each variable to maintain it. But this would add complexity to the code. So if your issue can be addressed in some other way, maybe you should go that way.

Again, only understanding the root cause of your problem will allow us to make the right design choice to fix it.

from capistrano-dotenv-tasks.

Yeah I understand that could be a solution. I will not try any solution right now, I do find weird that a quote could break something too. I was wondering if keeping the values as they were before shouldn't be the default behaviour of this gem, that's all. So that's what I was trying to point it out.

In the dotenv readme page it says that accept both values with and without quotes. Since "#" it turns into a comment you can quote it to have a value like "my#value".

The app that I was working on use this gem https://github.com/tapajos/highrise
There is one file in the app to configure all variables to be used in that gem and those values come from ENV variables, like in the example in my last comment.

And the part that broke my deploy was in the precompile part. It couldn't complete because the gem(highrise) said something went wrong and stopped the precompile. Turning my .env to the old one, with the values without quotes, made it work.

Even though there is nothing wrong with the quotes, it probably is something wrong with the gem highrise, maintain the same values is seems more right for me.

If you want to, you can close the issue and I will work more into find a way to keep both quoted and unquoted values as they were and I will open the issue with a PR for you to consider.

from capistrano-dotenv-tasks.

Hi @cassioscabral,

That seems perfect to me. I close this issue and wait for your PR.
Thanks for taking the time to enhance this gem !

from capistrano-dotenv-tasks.

Hey @cassioscabral the updates in PR #2 should fix you issue if it's actually linked to the quoting. Now there's no more quotes. Fixes there are merged and on rubygems

from capistrano-dotenv-tasks.

@vala awesome =)

from capistrano-dotenv-tasks.