fabric/fabric — Issue #531: Rethink env re: configuration & shared datastruct
Author: bitprophet
Created: 2012-01-17 22:19:47+00:00
State: open
Labels: 2.x

Fabric's `env` dictionary (`_AttributeDict`) has always functioned as a catchall for both effecting configuration changes, reading current configuration values, and storing user data between runs.

This is problematic in a number of ways:

* It's generally confusing in the "one thing used for multiple purposes" sense
* It's unclear which keys affect behavior when updated, and which are read-only (see: `env.host` vs `env.host_string`)
* Users never truly *needed* it for their own (non-default) keys, as they could simply use their own in-fabfile module-level global data store (since that's all `env` is in this context -- a top level variable in `fabric.state`.)
* It's possible to shoot oneself in the foot by accidentally overwriting config-related keys. Users should not really have to memorize the builtin config keys, which is the only good way to avoid this.
* Counterpoint: Python programmers *do* have to memorize the builtins or suffer bugs when redefining e.g. `map`.
* However, we have the power to make this a non-issue, and the problem is typically more subtle with us (i.e. in Python the problem is usually only triggered by trying to use the real builtin elsewhere; in Fabric you can screw things up with a single overwrite.)

The minimum solution should probably involve splitting out configuration related values from read-only and user ones, most likely ditching the recommendation for the "user" values entirely.

Ideally, use an approach that retains the user-friendly/terse aspects (e.g. `if env.some_setting: ...` versus `if config.get('some_setting')`) while making things clearer/more explicit.