# Ansible constants vs defaults. **URL:** \ **Category:** Ansible Project\ **Created:** [June 8, 2012, 7:32pm UTC](https://forum.ansible.com/t/ansible-constants-vs-defaults/11606 "2012-06-08T19:32:33Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![Timothy\_Appnel](https://avatars.discourse-cdn.com/v4/letter/t/e5b9ba/32.png) [@Timothy\_Appnel](https://forum.ansible.com/u/Timothy_Appnel)\ **Post date:** [June 8, 2012, 7:32pm UTC](https://forum.ansible.com/t/ansible-constants-vs-defaults/11606/1 "2012-06-08T19:32:33Z")
One more implementation question. It's pretty clear that we are going to have a different type of setup here. I respect that. Rather than have every user input all the switches to override the defaults every time, we'd like to have them automatically default to ones that are most common here. Besides the few environment vars that have been pointed out to me here, how and where do I set them? I see them in constants. Are they really constants (can't/shouldn't be changed) or are they defaults? If the latter, how should they be set to suit a particular environment? \ ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [June 8, 2012, 7:48pm UTC](https://forum.ansible.com/t/ansible-constants-vs-defaults/11606/2 "2012-06-08T19:48:33Z")
constants.py is part of the source code, but a few can be overridden by environment variables or command line flags, yes. you should never edit constants.py: [https://github.com/ansible/ansible/blob/devel/lib/ansible/constants.py](https://github.com/ansible/ansible/blob/devel/lib/ansible/constants.py) but you can easily set all the ANSIBLE\_FOO variables in your bash profile, etc, or use bash aliases It is probably a good idea to make various other things settable via the environment too (like the timeout, etc). Saves writing wrapper scripts or setting aliases when you don’t want to do that. Hopefully that answers the question. ---
**Author:** ![Timothy\_Appnel](https://avatars.discourse-cdn.com/v4/letter/t/e5b9ba/32.png) [@Timothy\_Appnel](https://forum.ansible.com/u/Timothy_Appnel)\ **Post date:** [June 8, 2012, 7:57pm UTC](https://forum.ansible.com/t/ansible-constants-vs-defaults/11606/3 "2012-06-08T19:57:58Z")
> Hopefully that answers the question. It does. I can work up a patch for that. Anyone have specific vars to include/exclude here? \ ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [June 8, 2012, 10:04pm UTC](https://forum.ansible.com/t/ansible-constants-vs-defaults/11606/4 "2012-06-08T22:04:17Z")
Great. I’d say add optional env variables for all of them, following the same pattern as the others. ---
**Author:** ![Timothy\_Appnel](https://avatars.discourse-cdn.com/v4/letter/t/e5b9ba/32.png) [@Timothy\_Appnel](https://forum.ansible.com/u/Timothy_Appnel)\ **Post date:** [June 8, 2012, 10:16pm UTC](https://forum.ansible.com/t/ansible-constants-vs-defaults/11606/5 "2012-06-08T22:16:07Z")
I already forked the devel branch and made changes in a branch of my own. I didn't create such a mechanism for the two passwords or the private key constants. That didn't seem like a good idea to me, but I'm open to changing that if I'm mistaken. I also left connection and connection\_opts as is for now to discuss the later -- the value is a list. How should a list get represented? Comma delimited? Space? Colon? All the above? It occurred to me why you might want to add a plugin folder under connection now do opts can be implicitly determined rather than explicitly. \ ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [June 9, 2012, 1:28am UTC](https://forum.ansible.com/t/ansible-constants-vs-defaults/11606/6 "2012-06-09T01:28:39Z")
> I already forked the devel branch and made changes in a branch of my own. I didn’t create such a mechanism for the two passwords or the private key constants. That didn’t seem like a good idea to me, but I’m open to changing that if I’m mistaken. The key file could be useful, agreed on passwords. > I also left connection and connection\_opts as is for now to discuss the later – the value is a list. How should a list get represented? Comma delimited? Space? Colon? All the above? It occurred to me why you might want to add a plugin folder under connection now do opts can be implicitly determined rather than explicitly. A variable like ANSIBLE\_CONNECTION is reasonable. The list is actually just the list of all possible valid connection types, so that shouldn’t be user specifiable anyway. ---
**Author:** ![Timothy\_Appnel](https://avatars.discourse-cdn.com/v4/letter/t/e5b9ba/32.png) [@Timothy\_Appnel](https://forum.ansible.com/u/Timothy_Appnel)\ **Post date:** [June 9, 2012, 8:14pm UTC](https://forum.ansible.com/t/ansible-constants-vs-defaults/11606/7 "2012-06-09T20:14:04Z")
> The key file could be useful, agreed on passwords. OK. I will add that in to my code before I issue a pull. > A variable like ANSIBLE\_CONNECTION is reasonable. Likewise. > The list is actually just the list of all possible valid connection types, so that shouldn’t be user specifiable anyway. OK, but what does a developer like myself or Darren do when we develop our own connectors to support something other than sudo? Is this where scanning anything under connector plugins would need to happen? ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [June 9, 2012, 8:15pm UTC](https://forum.ansible.com/t/ansible-constants-vs-defaults/11606/8 "2012-06-09T20:15:56Z")
> OK, but what does a developer like myself or Darren do when we develop our own connectors to support something other than sudo? Is this where scanning anything under connector plugins would need to happen? Depending on complexity (assuming it just inherits from the others), we could just incorporate it into ansible proper. If we want to make things look in an (additional) plugins directory, that’s fine, though the core ones should always be imported. ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [June 9, 2012, 9:16pm UTC](https://forum.ansible.com/t/ansible-constants-vs-defaults/11606/9 "2012-06-09T21:16:55Z")
Realizing I didn’t answer the right question. That list is fed to the opt parse module IIRC as a list of valid choices. If the plugins are made more plugin-ey, they would just have a name, and it would raise an error if a plugin didn’t exist of that name. In other words, yes, this variable has to go away. –Michael ---
**Author:** ![Timothy\_Appnel](https://avatars.discourse-cdn.com/v4/letter/t/e5b9ba/32.png) [@Timothy\_Appnel](https://forum.ansible.com/u/Timothy_Appnel)\ **Post date:** [June 12, 2012, 6:56pm UTC](https://forum.ansible.com/t/ansible-constants-vs-defaults/11606/10 "2012-06-12T18:56:11Z")
Having gotten my more environmental variable defaults in the pull request queue, I was starting to take a first crack at making connections pluggable. I was looking to handle loading any additional connections in the connection init where the local and paramiko are imported and instaniated. There is one snag though. Each transport has its own connection class. The local transport instanitates LocalConnection, the paramiko transport instaniates ParamikoConnection. So I can import a connection class, but I don’t really know what class to instantiate in there without addition input. So what to do? Convention over configuration is preferable to me, but I’m not sure what is the best way to implement that. Uppercase the first letter and append Connection? Thoughts? ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [June 12, 2012, 7:00pm UTC](https://forum.ansible.com/t/ansible-constants-vs-defaults/11606/11 "2012-06-12T19:00:36Z")
typically in those cases I define a top-level factory method in the module like so, where every module has the same method defined: def create(parameters): return new FooClass(parameters) class FooClass(object): … stuff … ---
**Author:** ![Timothy\_Appnel](https://avatars.discourse-cdn.com/v4/letter/t/e5b9ba/32.png) [@Timothy\_Appnel](https://forum.ansible.com/u/Timothy_Appnel)\ **Post date:** [June 12, 2012, 7:35pm UTC](https://forum.ansible.com/t/ansible-constants-vs-defaults/11606/12 "2012-06-12T19:35:45Z")
Sounds good. Skip that level of abstraction in core classes? Relatedly, shouldn’t all connection classes inherit from a base connection class rather than object? ---
**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\ **Post date:** [June 12, 2012, 7:41pm UTC](https://forum.ansible.com/t/ansible-constants-vs-defaults/11606/13 "2012-06-12T19:41:15Z")
> Sounds good. Skip that level of abstraction in core classes? Skip that in non-plugin classes? Yes. > Relatedly, shouldn’t all connection classes inherit from a base connection class rather than object? It’s kind of unnecessary. Duck typing versus interfaces.