feat: all cli options available as FASTAPI_<opt> *BREAKING* recently added PORT envvar

[babs]

Add environment variable for all cli options and prefix them with FASTAPI_

Will break the recently added PORT envvar

Feedback welcome, @patrick91 and @tiangolo

[patrick91]

hi @babs! thank you for the PR 😊

The reason why we went with PORT is because is used by different hosting providers, so you could do fastapi run and it would use the correct port.

For the other flags, I don't think it is worth adding environment variables. Also I'm working on adding support for specifying some of those flags in the project.toml file 😊

[babs]

in which contexte are you talking about hosting provider ?
I'm wondering which one doesn't let you decide the name of your env vars.

Considering containerization as said in the proposal (#151), ENV VARS are first class citizen and using a file is neither a standard nor easy to setup.
Still in a containerization env, PORT could refer to other thing than fastpi's one [like metric one], but I'd say others could accommodate.
I'd propose to remove the FASTAPI_ prefix but it has issue with PATH that has meanings beyond FastAPI config

I don't see any argument to not allow any cli option to be overridden.

[patrick91]

in which contexte are you talking about hosting provider ? I'm wondering which one doesn't let you decide the name of your env vars.

Just one example: https://docs.railway.com/guides/public-networking#port-variable, I'm sure there's others that do the same thing, in there you can do fastapi run and it will get the correct port 😊

Considering containerization as said in the proposal (#151), ENV VARS are first class citizen and using a file is neither a standard nor easy to setup. Still in a containerization env, PORT could refer to other thing than fastpi's one [like metric one], but I'd say others could accommodate. I'd propose to remove the FASTAPI_ prefix but it has issue with PATH that has meanings beyond FastAPI config

I don't see any argument to not allow any cli option to be overridden.

I don't think adding all these environment variables add valuable benefits to users, when you can do:

fastapi run --host $FASTAPI_HOST

(and it is a bit different for PORT since it is usually provided by hosting providers 😊)

hope this explanation clarifies your doubts :D

[babs]

I don't think adding all these environment variables add valuable benefits to users, when you can do:

fastapi run --host $FASTAPI_HOST

As stated this is not suited for general container orchestration. [One example among others is the worker count being adjusted based on the environment provided by the orchestration system]

I've proposed another MR taking advantage of both usage (#217)