2018 update: this is an old, old ticket and it is primed to actually be implemented now that 2.0 is available to build features on top of.

The tl;dr is that users need ways to store rich data about their target hosts (and, usually, groups or "roles"), first, and then need a way of addressing that information when doing API or CLI level things, second.

Fabric 2 is built on Invoke which has a powerful configuration system, which is then exposed to tasks via a 'context' object. It seems likely that we will build this feature on those, something like (but not necessarily limited to):

• Standardize on some relatively generic config-style format for representing hosts; basically Connection's parameters (user, hostname, port, connect_kwargs, timeout, etc etc) and probably with a bit more on top
  • or at least the opportunity for users to put arbitrary data on top and have that show up in the objects exposed to the user at runtime
• Update Context so it has a lightweight link to some other class or classes which turn the 'raw' config into usable API objects, based on some query or lookup
  • Open question is whether these show up as actual Connections or if there's an intermediate representational class like Host

For example (again: just an off the cuff example!) perhaps we'll set it up so host data gets its own config-style file that lives alongside the regular config files - say, $PROJECT/hosts.(yml|json|py|etc):

web1:
  host: web1
  # Implicit local user, as with Connection
web2:
  host: web2
  user: admin2
  port: 2223
db:
  # Implicit dict-key-is-the-host-value, i.e. implicit "host: db"
  user: dbadmin

Then perhaps there's something like this (using pure Invoke style tasks for now, though certainly this would want the ability to use -H or decorators to select target hosts to 'wrap' the task, as in v1):

@task
def deploy_webs(c):
  # Assuming auto-creation of Connection objects...
  for cxn in [c.find_host('web1'), c.find_host('web2')]:
    cxn.run("hostname")

There are a whole lot of different ways we could slice and dice this, and a lot of directions that it could be extended in; the emphasis should be on giving users as much power and control as reasonably possible and then getting out of their way. Ideally all we'll do is standardize on some very basic way of shoveling data into Connection objects, and add support to the core CLI exec framework to arrive at something resembling Fabric 1 re: selecting execution targets.

All while exposing these mechanisms publicly so advanced users can take matters into their own hands - again I expect anybody beyond the most basic use cases to be highly likely to fall back on a "regular Invoke style tasks + making the needful API calls within those task bodies" approach.

Original description

Right now a "host" is solely limited to user/hostname/port. Would be nice, even just for user fabfiles, to store additional information such as operating system, per-host settings like env.shell, and so forth.

Note that this may (or may not) be a good time to reconsider changing the default value of shell to /bin/sh.

Originally submitted by Jeff Forcier (bitprophet) on 2009-07-20 at 05:02pm EDT

Relations

• Duplicated by /bin/bash is not always available – per host shell configuration? #43: /bin/bash is not always available – per host shell configuration?
• Related to In some situations, pressing Enter does *not* reuse the previous password #97: In some situations, pressing Enter does not reuse the previous password
• Related to env.port not honored if host string lacks port specification #138: env.port not honored if host string lacks port specification
• Related to Make use of ssh_config where possible #3: Make use of ssh_config where possible
• Related to Use decorator to define tasks #76: Use decorator to define tasks