-
Notifications
You must be signed in to change notification settings - Fork 1.3k
add: warn when recursively adding large files #1935
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
Conversation
|
@MrOutis ? |
|
Sorry, @efiop , forgot to push changes |
tests/func/test_add.py
Outdated
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.
Let's define this config fmt somewhere and use it both in the code itself and in the test. No real need to copypaste it.
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.
@efiop , I think there's no harm in copy pasting constants on the test, at least in this case. 🙂
If we are going to take this approach for every log message that we are testing, we would end with a lot of constants across the code base.
This is different from having a module with constants like the one used for localization/internationalization purposes (strings.xml - android, locale/en.yml - rails, etc.).
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.
@MrOutis But at least you would only have to modify that message in one place. There is no harm in using constants, actually, it is strongly prefered over copypasting.
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.
Agree, @efiop , it is better to use constants than copy pasting to reuse code, but not to reuse code in tests.
It is kind of like a purist perspective, I guess, that you are modifying the interface of an object by adding another attribute just for the sake of testing, otherwise it wouldn't be needed.
I will change it on my patch, but just wanted to share my perspective 🙂
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.
@MrOutis Thanks! 🙂 I agree that sometimes generalization might be too much, but in this case, it is a fairly static big message, so copypasting it would simply bloat our code. Especially since the point of that test is to simply make sure that the message is printed, not to verify the contents of it.
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.
@efiop , if we add the file name to the warning "You are adding a large directory '{target}' recursively," is not static anymore; we would have something like:
# dvc/repo/add.py
WARNING_ADD_LARGE_DIR_RECURSIVELY = (
"You are adding a large directory '{target}' recursively,"
" consider tracking it as a whole instead.\n"
"{purple}HINT:{nc} Remove the generated stage files and then"
" run {cyan}dvc add {target}{nc}"
)
# ...
logger.warning(
WARNING_ADD_LARGE_DIR_RECURSIVELY.format(
purple=colorama.Fore.MAGENTA,
cyan=colorama.Fore.CYAN,
nc=colorama.Style.RESET_ALL,
target=target,
)
)can we skip it this time 😛 ?
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.
Indeed, when target is interlaced with colours it is not fun to bother around with partial string formatting. Deal 🙂
Have you followed the guidelines in our
Contributing document?
Does your PR affect documented changes or does it add new functionality
that should be documented? If yes, have you created a PR for
dvc.org documenting it or at
least opened an issue for it? If so, please add a link to it.
Close #1758