You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is insufficient documentation for build-time and runtime feature flags.
Use Case
Dockerfile Feature Flags
e.g. DIRENV_ENABLED
Geodesic Wrapper Script Feature Flags
e.g. GEODESIC_MAC_FORWARD_SOCKET
Describe Ideal Solution
Add an easily-maintainable page (perhaps with two tables — one for build-time feature flags and one for runtime feature falgs) in docs/. Probably, it's going to be easier to maintain if doesn't intend to be entirely comprehensive. I.e. a "Commonly-used feature flags" page is probably ideal.
Alternatives Considered
Don't document feature flags at all? i.e. let the code speak for itself?
I would suggest arrange such that the community can contribute. For example, I've spent a bit of time in geodesic and would like a section to document some things that n00bs might find interesting: Adding how to customize the wrapper script for install, node via nvm to geodesic as a tool, use starship for the prompt instead of the default prompt, etc.
Also:
See, for example "New options for customizing command line prompt appearance" in the Release Notes for v0.149.0
This example should be part of this customization documentation, and should simply be referenced in the release notes. Scrape the release notes for nuggets like this that can become part of this section
@korenyoni@Nuru just wanted to voice my support for this issue... Geodesic could obviously use as much documentation as it can get considering all the great work you folks have built into it. 👍
Have a question? Please checkout our Slack Community or visit our Slack Archive.
Describe the Feature
There is insufficient documentation for build-time and runtime feature flags.
Use Case
Dockerfile Feature Flags
DIRENV_ENABLED
Geodesic Wrapper Script Feature Flags
GEODESIC_MAC_FORWARD_SOCKET
Describe Ideal Solution
Add an easily-maintainable page (perhaps with two tables — one for build-time feature flags and one for runtime feature falgs) in
docs/
. Probably, it's going to be easier to maintain if doesn't intend to be entirely comprehensive. I.e. a "Commonly-used feature flags" page is probably ideal.Alternatives Considered
Don't document feature flags at all? i.e. let the code speak for itself?
Additional Context
direnv allow
persistence between sessions #762The text was updated successfully, but these errors were encountered: