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

Make get_pings include locally defined services #83

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

vladfedoriuk
Copy link

@vladfedoriuk vladfedoriuk commented Apr 14, 2024

Summary

This pull request makes it possible to retrieve the pings from locally defined services, as discussed in #81 and referenced to in #82.

Pull Request Check List

  • Typos aside (please, always submit typo fixes!), I understand that this pull request may be closed in case there was no previous discussion.
  • Do not open pull requests from your main branch – use a separate branch!
    • There's a ton of footguns waiting if you don't heed this warning. You can still go back to your project, create a branch from your main branch, push it, and open the pull request from the new branch.
    • This is not a pre-requisite for your your pull request to be accepted, but you have been warned.
  • Added tests for changed code.
    • The CI fails with less than 100% coverage.
  • New APIs are added to our typing tests at https://github.com/hynek/svcs/blob/main/tests/typing/.
  • Updated documentation for changed code.
    • New functions/classes have to be added to docs/core-concepts.md or one of the integration guides by hand.
    • Changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated directives.
      • The next version is the second number in the current release + 1. The first number represents the current year. So if the current version on PyPI is 23.1.0, the next version is gonna be 23.2.0. If the next version is the first in the new year, it'll be 24.1.0.
  • Documentation in .rst and .md files is written using semantic newlines.
  • Changes (and possible deprecations) are documented in the changelog.
  • Consider granting push permissions to the PR branch, so maintainers can fix minor issues themselves without pestering you.

@@ -194,6 +194,10 @@ def __del__(self) -> None:
stacklevel=1,
)

def __iter__(self) -> Iterator[type]:
Copy link
Author

Choose a reason for hiding this comment

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

I would appreciate an input - whether adding this method is OK and if so, where / how should it get documented

Copy link
Owner

Choose a reason for hiding this comment

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

Since this looks like #66, it's worth adding, but it might better as a separate PR for the reason alone that I'm not sure how long this one will take and it seems less controversial/decision-heavy.

Copy link
Author

Choose a reason for hiding this comment

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

Could this method only be included in another PR? Or should registered services inspection be more extensive?

Copy link
Owner

Choose a reason for hiding this comment

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

Yes, adding __iter__ in a separate PR is what I meant. Two changelog entries are a strong indicator that a PR is doing too much. 🤓

I also do think that the inspection could use more knobs, but this would be a start.

another_service_ping.assert_not_called()
local_another_service_ping.assert_called_once()

def test_local_services_without_pings_do_not_discard_global_pings(
Copy link
Author

Choose a reason for hiding this comment

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

I assumed such behavior would be the most "predictable" from the end-user perspective, but I was not quite sure about this change. Would you find it valid to make it work like that?

Copy link
Owner

Choose a reason for hiding this comment

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

yeah hm this is hard. There's two contradicting issues here:

  1. discarding is a breaking change
  2. If I overwrite a definition, that's what I want to use.

But more specifically, it's the decision of the user to add a new definition of a service with a ping. I feel like discarding follows the wish of the user? They can define a new type based on the old type if they want to preserve the old definition.

Given that svcs core concept are types, I feel like we should respect it when a user says "Connection is now this new thing."

But don't change anything, yet.

Copy link
Author

Choose a reason for hiding this comment

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

Ok, so regardless of whether a new definition contains a ping, the latest defined service (could be local) must be used?

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.

None yet

2 participants