fab-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fab-user] import bug


From: Rob Cowie
Subject: Re: [Fab-user] import bug
Date: Thu, 14 May 2009 09:36:30 +0100

This is loosely related to a question asked recently when I demo'd fabric at work; why can't I pass a path to a fabfile as an argument to the fab command?

Searching for the fabfile is convenient in most cases but is considered by some as a constraint. Specifically, the use case described by one of my collegues involved the use of multiple deployment files in the same dir with different, app specific names (ie not fabfile.py)

An extension to that functionality might be to accept urls to remote fabfiles that are fetched and evaluated.

Perhaps this ability would be better implemented in fabric.contrib rather than messing with the internals for an uncommon use case?

As this is my first post to the list may I say thankyou for everyones work on fabric.

Rob Cowie

On 13 May 2009, at 22:21, "Jeff Forcier" <address@hidden> wrote:

Hi Peter,

Assuming I read you correctly, this means the directory containing
your fabfile is already in sys.path (i.e. you've added it to your
shell PYTHONPATH or similar), and comes after the location of your
Fabric source checkout, correct? In this situation, yes, I think it
would pick up Fabric's fabfile module before yours.

For what it's worth, I use Fabric with setup.py develop, and don't
have this problem -- most likely because my fabfile's containing
directory is *not* in my normal PYTHONPATH and thus, it's being added
explicitly to the very front of the path by line ~10 in
load_fabfile().

Let me know if I was right about your scenario (and if so, I'm curious
why it's set up that way, though I'm not implying by this that you're
doing anything wrong -- literally just curious!) and we can figure out
what the best approach is.

Offhand I think I could simply tweak the behavior such that if your
situation (containing dir is already in sys.path) comes up, that dir
gets moved temporarily to index 0, just like when it has to insert it,
and is then restored to its original index afterwards.

This ought to be sufficiently clean, while ensuring that the found
fabfile module is the imported one, no matter what.

Best,
Jeff

On Wed, May 13, 2009 at 4:52 PM, Peter Sheats <address@hidden> wrote:
So in regards to this code:

def load_fabfile(path):
    """
Import given fabfile path and return dictionary of its public callables.
    """
    # Get directory and fabfile name
    directory, fabfile = os.path.split(path)
# If the directory isn't in the PYTHONPATH, add it so our import will
work
    added_to_path = False
    if directory not in sys.path:
        sys.path.insert(0, directory)
        added_to_path = True
    # Perform the import (trimming off the .py)
    imported = __import__(os.path.splitext(fabfile)[0])

# Remove directory from path if we added it ourselves (just to be neat)
    if added_to_path:
        del sys.path[0]
# Return dictionary of callables only (and don't include Fab operations
or
    # underscored callables)
    return dict(filter(is_task, vars(imported).items()))


What it doesn't check is what is first on the path -- so all i have been getting is the fab commands (build_docs, push_docs, etc) whenever i run fab
-l even though it is finding my fabfile.py.  The reason is because my
src/fabric command is in my path before the "directory" mentioned in the code above is. So all that ever gets in the imported list is commands from
fabric's fabfile.py.

Maybe this is because I run python setup.py develop? Not sure if there is
any reason for me to have src/fabric in my path...

Peter

_______________________________________________
Fab-user mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/fab-user




_______________________________________________
Fab-user mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/fab-user

--
This message has been scanned for viruses and
dangerous content by our Antivirus and Antispam MailScanners
and is believed to be clean.
If you find that this message does contain a virus or came as spam,
please contact PIRC IT:

address@hidden
--



--
This message has been scanned for viruses and
dangerous content by our Antivirus and Antispam MailScanners
and is believed to be clean.
If you find that this message does contain a virus or came as spam, please contact PIRC IT:

address@hidden --






reply via email to

[Prev in Thread] Current Thread [Next in Thread]