Skip to content

Make some env vars optional for easier dev setup #470

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

Closed
carols10cents opened this issue Nov 16, 2016 · 5 comments
Closed

Make some env vars optional for easier dev setup #470

carols10cents opened this issue Nov 16, 2016 · 5 comments
Labels
C-enhancement ✨ Category: Adding new behavior or a change to the way an existing feature works

Comments

@carols10cents
Copy link
Member

Right now cargo_registry::env panics if there isn't a value set for an env var, so you can't run the server locally unless you set values for everything in .env.

If you're just working on part of the backend that you don't need users logged in for, there's no reason to have to set up github tokens and all that.

I tried to make this easier to set up by setting the values in .env.sample to "", which gets around the panic, but apparently that caused problems with zsh.

I think it'd be better to have another function, like env_with_default or something, and maybe warn that functionality that needs that env var isn't going to work?

I'm happy to do this, just not right this second, so I wanted to open this to remind me (and maybe entice someone else to do it, i don't think it would be very hard #famouslastwords)

@alexcrichton
Copy link
Member

Sounds good to me!

@kelcecil
Copy link
Contributor

I'd be happy to take this task.

@kelcecil
Copy link
Contributor

My thought is that we may want to still panic for certain environment variables not being set where we absolutely can't progress. TEST_DATABASE_URL, S3_* variables, and GH_* variables would all be okay for defaults, but the Postgres URL and GIT_* variables would pretty much be required and should panic if not set. Thoughts?

@alexcrichton
Copy link
Member

@kelcecil yeah sounds good to me. We may want to assert that in production everything is set, but otherwise sounds good

This was referenced Feb 25, 2017
@carols10cents carols10cents added the C-enhancement ✨ Category: Adding new behavior or a change to the way an existing feature works label Aug 2, 2017
@carols10cents
Copy link
Member Author

I think we fixed this. If anyone hits this problem, please reopen!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement ✨ Category: Adding new behavior or a change to the way an existing feature works
Projects
None yet
Development

No branches or pull requests

3 participants