Re: [Fab-user] import bug

[Jeff Forcier]

Hi Rob,

I don't know what version of Fabric you're using currently, or whether
you're keeping abreast of the 0.9 development, but a -f/--fabfile
option was added to 0.9-alpha (it should be available in the 0.9a2
downloads) a couple of weeks ago:

http://github.com/bitprophet/fabric/commit/b8db844f2849633976f260d28a5bad630d0997e1

Fetching of remote fabfiles isn't a bad idea, but is probably
something better slated for the 1.0 or 1.1 releases. (I do think it
would work better as an update to the existing core fabfile
finding/loading functionality; contrib.* is generally for stuff
building on top of the core Fabric functionality, which this isn't
really.)

Best,
Jeff

On Thu, May 14, 2009 at 4:36 AM, Rob Cowie <address@hidden> wrote:
> 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
> --
>
>
>