Why does phoenix only provide a config/prod.secret.exs and not for dev and test?

[Theston E. Fox]

There may be a completely valid reason for this, but I thought it would make more sense for phoenix to generate:

config/dev.secret.exs

config/test.secret.exs

along with the already generated config/prod.secret.exs

Most of the dev/test config is standard so would want to be in the config/dev.exs file so it can be committed to version control

However, I find that there are always some things that I want to keep out of version control, even if it's just my local db password or other specific config items for my set up.

What would the negative side be to having a dev.secret and a test.secret?

[benwil...@gmail.com]

There is nothing special about prod.secret.exs. It's far more common to have shared secrets in production than dev or test, but if you have some you can trivially create your own dev.secret.exs files.

[Theston E. Fox]

I am already creating my own dev and test secret, my question was why not have phoenix do it by default.

Is it better to have phoenix create them and not use them, or not create them and expect the author to create their own solution for each project?

[benwil...@gmail.com]

I imagine if there was a lot of support for having them it could be added to the defaults, I'm just not sure that it's a common use case. What belongs there? The special thing about prod.secret.exs is that it's by default in the .gitignore file, because it's supposed to contain production secrets that need to be distributed very carefully. The same can't be said for development or test related database configuration in any case I can think of.

[Chris McCord]

We've gone back and forth on this and Ben describes our thinking well. The generated files have always been a balance between sane defaults and not too many files that may go unused or need manually deleted. That said, I haven't ruled our dev.secrets.exs for a future release.

--
You received this message because you are subscribed to the Google Groups "phoenix-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phoenix-talk...@googlegroups.com.
To post to this group, send email to phoeni...@googlegroups.com.
Visit this group at https://groups.google.com/group/phoenix-talk.
To view this discussion on the web visit https://groups.google.com/d/msgid/phoenix-talk/d546238a-b105-41a7-99a5-f80b5e5fefb0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Theston E. Fox]

Would it be possible to just not auto generate the files with the phoenix.new mix task and just have the config check for the existence of them and include them if necessary?

I usually just do this in my config.exs

import_config "#{Mix.env}.exs"

if File.exists? "config/#{Mix.env}.secret.exs" do

  import_config "#{Mix.env}.secret.exs"

end

Then if I have a dev.secret.exs then it is used.

And to address the point as to why is a dev/test secret desirable.... There is nothing to say my database credentials will be the same as another developer working on the project, so if I commit the dev.exs file with my credentials, it just causes the other developer trouble.

[Steve Domin]

I like the way it is now, you don't need one for simple projects and it's really easy to create a dev.secret.exs if you do.

To view this discussion on the web visit https://groups.google.com/d/msgid/phoenix-talk/2e1cb4da-79ac-4edd-ba5b-9d0a934f5ebf%40googlegroups.com.

[Theston E. Fox]

That's why I quite like the idea of checking for the existence of the env.secret.exs file. Then you can just git ignore `*.secret.exs` and if you create one it will be used, if you don't then it wont be included anyway.

It's what I do at the moment, I just thought it may be a nice suggestion for the core product to do this by default.

I'd happily do the pull request on it, but thought I'd see if people agreed before doing it then getting in rejected :)