Skip to content

summon: fixes and dvcx prereq #3101

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

Merged
merged 5 commits into from
Jan 13, 2020
Merged

summon: fixes and dvcx prereq #3101

merged 5 commits into from
Jan 13, 2020

Conversation

Suor
Copy link
Contributor

@Suor Suor commented Jan 10, 2020

No description provided.

@efiop efiop requested a review from a user January 11, 2020 03:38
Copy link
Contributor

@efiop efiop left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check the deep source report. Looks like you are intriducing the same issue that you've reported recently in the private converstaions 🙂 The open one, but now with summon.

for out in outs:
repo.cloud.pull(out.get_used_cache())
out.checkout()
raise SummonError(str(exc)) from exc
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess users of summon are not going to set up the DVC logger, right?
These messages would duplicate the output (exc - exc).
@efiop introduced an extra keyword to prevent that: extra={"tb_only": True}, if it is the case, maybe you could use it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The cause will have the same message as SummonError but different traceback, I don't think this is an issue. I can't use extra={"tb_only": True} because I am not using logger.exception() but simply raise an exception.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Suor I agree with @MrOutis , it will look ugly that way. It is a formatting issue, right? Why not SummonError("invalid formatting") from exc or something like that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@efiop because a user won't see the issue until he/she scrolls up past traceback. "invalid formatting" is useless, you need to see, which key is absent/extraneous/has wrong type.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missed that it is not meant to go through our usual logger logic. I'm fine with it 👍

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Suor , left some questions, looks good 👍

Suor added 2 commits January 13, 2020 15:19
It's now thread-safe, but the rest is still relevant.
- proper doc-string for prepare_summon()
- summon -> summon_dict in summon() to not overwrite a glo bal name.
This was not a bug, but a bad practice, which might have caused some
issues in the future.
- better name for _get_object_spec()
@Suor
Copy link
Contributor Author

Suor commented Jan 13, 2020

Should be mergable now.

@efiop efiop merged commit 100dde1 into iterative:master Jan 13, 2020
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

Successfully merging this pull request may close these issues.

2 participants