-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Implement straight-to-remote functionality #5198
Conversation
8ab4626
to
7a89af6
Compare
For the record: while we are reviewing the technical part, let's start creating docs for this, to make sure we are on the same page in terms of CLI semantics. |
"--to-remote", | ||
action="store_true", | ||
default=False, | ||
help="Download it directly to the remote", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about something like
help="Download it directly to the remote", | |
help="Track an external target, but don't move it into the " | |
"workspace, nor cache it. Push it to remote storage " | |
"instead.", |
May need formatting
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
parser.add_argument( | ||
"-r", | ||
"--remote", | ||
help="Remote storage to download to", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should definitely be included in --to-remote
(let it accept a remote name as argument) to simplify the UI. add --to-remote --remote
looks fort of repetitive anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We actually thought about it and decided for the sake of consistency with other commands who works on the remote, it would better to just split it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also, in most cases it'll be just --to-remote
, right?
also, can an option in argparse be made to optionally accept a value - in this case we would have to make --to-remote [remote-name]
where remote-name is optional (default remote if not specified)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also, in most cases it'll be just --to-remote, right?
yes
also, can an option in argparse be made to optionally accept a value - in this case we would have to make --to-remote [remote-name] where remote-name is optional (default remote if not specified)
yes, the implementation is possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, the implementation is possible.
then, I guess, I don't have a strong preference I think. --remote
is good for consistency, but I would not say it looks critical to me, --to-remote
already reminds it a lot.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also, in most cases it'll be just --to-remote, right?
I'm not sure that most users employ default remotes. Do we know this?
I see the consistency argument but it's not that big a deal, and forcing the exact flag name causes other issues e.g. just add --remote
is meaningless (and forbidden, I think, or it it silently ignored?) + its an extra flag to doc/explain and maintain π
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that most users employ default remotes. Do we know this?
that's why we have default remotes at all. if we are not sure about this we should reconsider the whole logic we work with remotes then
add --remote is meaningless
agreed, I would not do this. may be keep only --to-remote <optional-name>
381c34e
to
67bfc45
Compare
c2ee258
to
d9e5385
Compare
Oops I meant to resolve my #5198 (review) above and accidentally I clicked on "Ready for review". Unfortunately you can't go back to draft status... Sorry! |
No worries, eventually I was going to also do that to get @efiop 's reviews! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great stuff! π₯
Work from this PR is needed for other PRs (e.g. overlapping with vdir functionality and even erepo refactor), so merging this as-is for now. Let's address the CLI and other leftovers on top.
local_tree = self.repo.cache.local.tree | ||
local_info = local_tree.path_info / tmp_fname() | ||
|
||
from_tree.download(from_info, local_info) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might not fit on the local filesystem π We could download a chunk and upload a chunk though and then assemble them. Or could just forbid transfering files as a whole for now.
Working on iterative/dvc.org/pull/2091, I'm assuming the concerns left above will be
|
Another thing to consider (BTW I meant considered/discussed, not necessarily addressed as in implemented): Similar to combining --to-remote and --remote for simplicity/usability, should --external (in
Cc @dberenbaum |
p.s. on that error message (unrelated to this issue, sorry) should it give a HINT to retry with |
@jorgeorpinel Good catch with |
I believe this already works with straigh-to-cache when the given output is within the repo, |
I haven't tested And sorry, I didn't understand the relationship between requiring explicit Anyway, my main rationale is that saving users from unnecessarily typing a flag that is always required is good for the UX (similar as with merging |
Would you create a ticket for the things in your mind (--external, --to-remote + --remote etc) @jorgeorpinel, it is hard to debate these stuff under a merged PR. |
Yeah let me do that because actually I think I'm still confused here π |
Part of #4520
β I have followed the Contributing to DVC checklist.
π If this PR requires documentation updates, I have created a separate PR (or issue, at least) in dvc.org and linked it here: Add docs regaring --to-remote option for add/import-urlΒ dvc.org#2091
Thank you for the contribution - we'll try to review it as soon as possible. π
Internal Tracker