-
Notifications
You must be signed in to change notification settings - Fork 116
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
No access to remote host name in local.transfer() #140
Comments
See this section in the docs: https://github.com/pstadler/flightplan#accessing-runtime-information Is this what you're asking for? |
For |
I am bumping up against this issue once again. @pstadler is there an easy way to accomplish this? My guess is not? Because the looping over the target hosts occurs within the |
This is a bug. Shouldn't be too hard to fix. Will try to do another release
pretty soon
…On 15 May 2017 at 02:55:41, Ravi Sarma ***@***.***) wrote:
I am bumping up against this issue once again. @pstadler
<https://github.com/pstadler> is there an easy way to accomplish this? My
guess is not? Because the looping over the target hosts occurs within the
local.transfer(), but I thought I'd ask to be sure.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#140 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAkoIZU9wZ-QyvnrUJ8Uw9hX69eVSZkhks5r56KNgaJpZM4IsKVE>
.
|
Ah sorry, I thought this is about another ticket. This is indeed hard to solve. Maybe you should simply roll with an own implementation running rsync in a local loop. |
Perhaps this is a poor usage pattern, but I have a need to access the remote host name or at least the target name, in
transfer()
(the files to be transferred are based on the remote hostname or target). In earlier versions I could do this using something likelocal.flight.flightplan.target.destination
(IIRC) but now I don't have that (I could fudge usinglocal._context.target
but I am guessing underscore prefixed properties should be treated as private following Unix conventions).I am wondering if this may be a general need, not just a peculiarity of my usage :-).
The text was updated successfully, but these errors were encountered: