Re: [Fab-user] Remaining issues (#8, #9, #10)

[Christian Vest Hansen]

Keeping _protected stuff from fabfiles was, as I recall it, to prevent
you from unknowingly wreaking havoc to fabrics internals, causing an
unpredictable array of errors to happen.

The assumption is, that operations and commands are a lot more visible
and so people wont try to override them unless they're gluton for
trouble.

But this concept of conditionally putting things in __builtins__ from
the fabfile is broken, and I always regarded it as a hack. Ideally,
we'd get to the point where we don't have to put anything in
__builtins__ from the fabfiles. But as I discovered both now and when
I started writing the first lines of Fabric, this is actually a
difficult thing to do in Python. The tools that let us load code in
their own isolated namespace and return Module object don't allow us
to prime said namespace with all our nice commands, operations and
decorators. And the tools that let us load code with a primed
namespace don't provide the isolation we want and hence the
__builtins__ hack. A third and (with good reason) unexplored option is
'manually' reading the fabfile, modifying the code to wrap it in our
custom isolation-thingy (whatever that ends up being) and then
compile() + eval(), but just trying to imagine the number of horrible
ways this can blow up makes my head spin.

On Sat, Oct 25, 2008 at 11:31 PM, Jeff Forcier <address@hidden> wrote:
> On Sat, Oct 25, 2008 at 5:08 PM, Christian Vest Hansen
> <address@hidden> wrote:
>>>> == 10. "_protected" names are discarded ==
>>>
>>> Unless I'm missing something, this hasn't been touched, but you also
>>> mentioned it's not pressing.
>>
>> I have not touched it, but it would definitely be nice to have.
>
> Honestly, I'd be all for updating the logic like so:
>
> for name, obj in captured.items():
>        if not name.startswith('_') and isinstance(obj, types.FunctionType):
>            COMMANDS[name] = obj
>        else:
>            __builtins__[name] = obj
>
> In other words, non-underscored functions become commands, and
> _everything_ else -- underscored functions, regular nonfunctions, and
> underscored nonfunctions -- gets tossed into the local namespace.
>
> If Niklas makes those changes to how fabfile state is stored, it may
> make some of this moot anyways, but as a general algorithm for
> stuff_in_your_fabfile => stuff_available_inside_commands I think it's
> probably the best way to go. Having a more robust state mechanism may
> also make it easier to deal with any problems in underscored methods
> (such as shadowing existing helper methods and so forth).
>
> -Jeff
>



-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.