Comments (7)
@sethlopezme You can already do this via the [global]
table. Check out the configuration API Docs for more details.
from rocket.
I'm leaning towards adding an environment variable. If I do go that route, I'm strongly in favor of using a ROCKET_
namespaced variable. I want to avoid accidental collisions, where a Rocket configuration parameter is accidentally set because some common environment variable was set for a different application.
How big is the impact from having the environment variable not be named PORT
? I imagine it would be a simple change to add ROCKET_PORT=$PORT
, and there's something nice about the self documenting nature of that line.
from rocket.
I've considered being able to pass the default configuration options via command line arguments (--port 312
) or environment variables (ROCKET_PORT=312
), or both, with some definition of precedence. Either of these would let you start rocket with a different port. The former can lead to confusion when an application has its own command line arguments, and so I prefer it less. I believe the latter would work for your use case, is that right?
An alternative, more radical solution is to allow any parameter to be set via any environment variable by specifying the variable in the Rocket.toml
file. Something like this:
[dev]
port = $PORT
Rocket would recognize the $
and require that the PORT
environment variable is set when parsing the config and use the variable's value (which must also parse) as the value of the parameter. But this seems very specialized. Kinda neat though.
from rocket.
We've used all these options in our projects and I'd say the environment variables are for me the best possible way of giving configuration for a running application. This way the deployment configuration handles the environment the application uses, including the secret keys.
Right now I don't really see the reasoning behind the specific configuration files.
The last solution you listed is actually the same Scala uses in its application.conf
. And if you go with the environment variables, please use the standard PORT
so there's no need for specific deployment configuration when deploying to Mesos.
from rocket.
The ability to set any parameter in Rocket.toml
via any environment variable is interesting. This would make it easier to build an application using the Twelve Factor App methodology. I think if this were to happen, there should be a way to define a "default" configuration, and then specify other options depending on the environment. Something like this?
# maybe omit "[default]"?
[default]
address = $APP_HOST
port = $APP_PORT
log = $APP_LOG_LEVEL
session_key = $APP_SESSION_KEY
[dev]
hi = "Hello!"
is_extra = true
This would be similar to having a .env
file with a little extra configurability. What are your thoughts?
from rocket.
Slating the ROCKET_{PARAM}
configuration method for 0.2.
from rocket.
This has been implemented and will ship in 0.2. From the docs:
+//! ## Environment Variables
+//!
+//! All configuration parameters, including extras, can be overridden through
+//! environment variables. To override the configuration parameter `param`, use
+//! an environment variable named `ROCKET_PARAM`. For instance, to override the
+//! "port" configuration parameter, you can run your application with:
+//!
+//! ```sh
+//! ROCKET_PORT=3721 ./your_application
+//! ```
+//!
+//! Environment variables take precedence over all other configuration methods:
+//! if the variable is set, it will be used as the value for the parameter.
+//!
from rocket.
Related Issues (20)
- how to return error as a Json from FromParam HOT 3
- Responder enums not serializing like expected HOT 1
- FileServer can serve pre-gzipped content if it exists on the filesystem HOT 1
- Cookies aren't read by get methods but it exists in the browser HOT 2
- HTTP3/QUIC support HOT 15
- Add HTMLStream HOT 5
- cookie removal and Microsoft Edge HOT 7
- Inject script to auto-reload browser when Rocket restarts
- Rocket App Hangs HOT 5
- DefaultListener::bindable() isnβt usable HOT 8
- Allow routes that match any method HOT 4
- Hyper and Rocket disagreeing on validity of URL HOT 3
- Allow from form macro to work on structs with range HOT 4
- Clippy Lint w/ FromForm derive HOT 7
- Possible Incompleteness HOT 1
- Possible Incompleteness HOT 1
- doc: change `&ContentType` with `&Accept` in the list of implementations of `FromRequest` HOT 1
- [Feature]: Enhanced State Mutation for Effortless Handling of Shared Resources HOT 5
- Guide navigation causes relative links inside articles to 404 HOT 1
- Redirection to a route which takes a vector parameter results in an error HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rocket.