Fabric: Additional roledefs keys beyond 'hosts' not loading into env

you can use below example as configure file , then add some internal function to handle fabfiles.py

like: list.db
interface|ip|password|role....
hope it will work for you.

There are several env keys used by fabric to determine which host(s) to connect to for each session, i.e. roles, effective_roles, hosts, host_string. And of course decorators as well.

That said, the roledefs is only a name mapping for grouping hosts, not necessary merged into env.hosts.

Defining the roledefs as a dict helps you organize other custom settings, next to hosts, that are role specific. You can access them via full env path, i.e. env.roledefs.web.foo

But, like you issue, and maybe expect, is that a role defined as a dict should get merged to the env root.
This is what i personally also use it for. I just haven't found a nice way to implement it and pull request yet, due to all the possible ways of actually set/get the "current" role(s) when executing a specific task, and the complexability when calling subtasks within tasks. Simply explained I do this by subscribing to changes to env and merging the role when the key roles gets set in env. But the "hard" part is to hold state and cleanup any role merging when new roles is used within the session.

env.roledefs.web.foo produces the error: AttributeError: 'dict' object has no attribute 'web'

I mean you could access it like a regular dict, env.roledefs['web']['foo'] but then I don't see why this functionality exists at all in Fabric, it's just a plain dict. It seems like this feature was implemented for a more useful reason?

Sorry, you're right, you have to access it like you say.

Currently theres no other reason than allowing you to group more role settings next to hosts.
But, when milestone 1.11 is released and #1092 exists, then it makes more sense.

Also #1088 is part of 1.11 which is similar to what your describing/expecting. But I haven't found a nice way, as i said, to implement merging of roledefs yet. Only proof-of-cocept in fork using "ugly" deep monkey-patching.

Ah alright that makes, I was beating my head against the wall thinking I was missing something :) Those referenced issue numbers look like they will help quite a bit whenever they roll. Thanks Jonas!

This is confusing and I think it should be noted in the documentation that these additional variables are not accessible outside of the roledefs.

@bitprophet Why has this been closed? The behavior of additional roledef keys hasn't changed, so is this a "won't fix"?