Enhancing require

[bitprophet]

Description

Currently require is called as a function inside of a running task, ideally the task would fail to start if the python env variables were not set. I also feel the syntax is improved by using a decorator, as it is more similar to a regular function
definition.

from fabric.contrib.require import Require

@Require("variable", "another")
def task(more_args):
    print(env.variable) # we can now expect this variable to be set

On failure I currently raise a NameError with the message containing a list of missing env variables as well as the wrapped function.

Implementation available on github

---

Originally submitted by Michael Jard (mjard) on 2010-07-30 at 06:17am EDT

Attachments

• require.py

[bitprophet]

Jeff Forcier (bitprophet) posted:

---

While I don't actually quite "get" the use case for require (it was put in before my time) I definitely acknowledge that as-is, having it available in decorator form makes a lot of sense. Thanks for filing the ticket!

I'd prefer a different implementation, though:

• Either a different name entirely, instead of capitalizing it (which isn't PEP8 friendly), or preferably just making the existing function capable of behaving as a decorator, if possible.
• It should behave the same as the existing function insofar as it calls abort instead of raising an exception -- mostly for backwards compatibility reasons. An overhaul of Fabric's error handling to be more library friendly (read: more exception raising) is due in the future anyways, but that would be post 1.0.

---

on 2010-07-30 at 10:19am EDT

[bitprophet]

Michael Jard (mjard) posted:

---

Example Use Case:
We use fabric for cluster provisioning here at Symantec, while it was originally very simple with one fabfile, it has ballooned into a multifile project of tasks that call other tasks with env variables being set in configuration file as well as being set in user prompts along the way. The decorator is used as last set of sanity checks to make sure all the needed configuration options have been set before running a task.

Implementation Issues:

• Decorator is currently implemented as a class, so I was following the naming conventions for classes. If you have a suggestion for a name, I'd love to hear it, I'm often not too creative.
• It'd be interesting to see if the existing implementation could be changed to support decorating without breaking existing code, though the resulting code would not be pretty.
• I am willing to modify to support abort instead for now.

---

on 2010-07-30 at 01:45pm EDT