Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

file_upload() behavior for lcd context incompatible with fabric put() #198

Open
elgow opened this issue Dec 6, 2015 · 4 comments
Open

Comments

@elgow
Copy link

elgow commented Dec 6, 2015

The put() method in fabric honors lcd context, but file_upload() does not. This makes file_upload() fail whenever an lcd context is in place because the either file_upload() code or put() will use the wrong path.

To reproduce this bug just do

cd 'different_local_directory'
with lcd('local_directory'):
file_upload(target_path, 'some_file_in_local_directory')

The relevant code from put is at fabric/operations.py:364

I'd have written a patch, but the behavior of put() wrt paths is complex enough that it seems wrong to duplicate it in file_upload() w/o refactoring fabric to expose it all for reuse.

@sebastien
Copy link
Owner

Would you mind writing a standalone test case for that? The function fabric.utils.apply_lcwd(path,env) would probably fix it and I could easily add it to file_upload.

@elgow
Copy link
Author

elgow commented Dec 11, 2015

Hello Sébastien,

I've attached a small fabfile that demonstrates both failure modes of file_upload proper operation of put().

It seemed to me that just using fabric.utils.apply_lcwd(path,env) might not be sufficient because of the way that put() deals with non-path arguments. There is this logic

local_is_path = not (hasattr(local_path, 'read') \
    and callable(local_path.read))

in put() for determining whether the source is a file or a path. I see that file_upload works only for paths, so fabric.utils.apply_lcwd(path,env) would work for that case, but some of the functionality of put() is lost.

Thank you for addressing my issue so quickly.

Ed

On Fri, 11 Dec 2015, Sébastien Pierre wrote:

Would you mind writing a standalone test case for that? The function fabric.utils.apply_lcwd(path,env) would probably fix it and I could easily add it to file_upload.


Reply to this email directly or view it on GitHub.[AK_suSlI9rQZ0yzybaTDJ1OjVu1UIbNNks5pOukLgaJpZM4GvmJt.gif]

@sebastien
Copy link
Owner

I think you forgot the attachment! file_upload is not meant to be a full replacement for put. You can still use Fabric's put if you want -- it's just that I had issues with put.

@elgow
Copy link
Author

elgow commented Dec 11, 2015

fabfile.py.gz
Sorry, here's the attachment again (sorry, trouble with script blockers).

Cuisine adds the mode settings, which would be ignored by put(), so it's nice to be able to stay within cuisine for most things. Still, if upload_file() worked with lcd() then that would cover the most common case of copying a local path to a remote path.

Thank you for creating cuisine. Whatever issues there may be with fabric and cuisine, they are still nothing compared to the pain of battling ansible as it tries to use YAML markup as a scripting language. One would have thought that imake and ant provided sufficient lessons in why that should not be done.

Ed

On Fri, 11 Dec 2015, Sébastien Pierre wrote:

I think you forgot the attachment! file_upload is not meant to be a full replacement for put. You can still use Fabric's put if you want -- it's just that I had issues with put.


Reply to this email directly or view it on GitHub.[AK_suVRa4Q2718c9o0JFvtPt4iuNQiPoks5pOx18gaJpZM4GvmJt.gif]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants