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

Drop multicall #147

Merged
merged 9 commits into from
Jun 4, 2020
Merged

Drop multicall #147

merged 9 commits into from
Jun 4, 2020

Conversation

goodboy
Copy link
Contributor

@goodboy goodboy commented May 18, 2018

Just to get some eyes on it as we approach 1.0!

Copy link
Member

@nicoddemus nicoddemus left a comment

Choose a reason for hiding this comment

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

LGTM!

Related to #59 btw.

@RonnyPfannschmidt
Copy link
Member

it should be noted that we require a breaking pytest release to update to this one

@nicoddemus
Copy link
Member

it should be noted that we require a breaking pytest release to update to this one

On pytest we probably will no longer pin pluggy after 1.0, so not sure we need to change pytest at all... users will be able to pin to pluggy<1.0 if they require to.

@obestwalter
Copy link
Member

Same for tox, I guess :)

@goodboy
Copy link
Contributor Author

goodboy commented May 18, 2018

@RonnyPfannschmidt yes @nicoddemus makes a good point: pytest need not be concerned with whether users still require __multicall__ since plugins can simply pin to pluggy <= 1.0 and everything should just work. That's the nice part of the graceful fade out of this subsystem.

@RonnyPfannschmidt
Copy link
Member

@tgoodlet @nicoddemus that ignores pytest possibly wanting to use new features of pluggy and the fact that pluggy is part of the public api of pytest, as such, break a part break the whole

i'd like to be pedantic about things there

@bluetech
Copy link
Member

bluetech commented Jun 2, 2020

Since pytest 6.0 is coming, maybe it's a good time to merge this, release pluggy 1.0 and require pluggy>=1.0,<2.0 in pytest 6.0? (I can do the pytest part)

@goodboy
Copy link
Contributor Author

goodboy commented Jun 2, 2020

@bluetech I'm in.

This has been getting put off for no real reason really.
I'll do the rebase onto recent master once back at the keyboard.

Tyler Goodlet added 2 commits June 3, 2020 12:01
Drop the `_LegacyMultiCall` type and it's recursion "fun".
We've got a faster and simpler function-loop approach now with
`pluggy.callers._multicall()` it's been doing great in production!

Resolves pytest-dev#59
@goodboy
Copy link
Contributor Author

goodboy commented Jun 3, 2020

Just working out some kinks from the rebase onto master.

@goodboy
Copy link
Contributor Author

goodboy commented Jun 3, 2020

Ok think I got it all.

One question, should I start a 1.0 tag here to get a dev version going?

Copy link
Member

@asottile asottile left a comment

Choose a reason for hiding this comment

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

Copy link
Member

@bluetech bluetech left a comment

Choose a reason for hiding this comment

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

Left some suggestions, other than that, LGTM!

@@ -38,7 +38,7 @@ def wrappers(request):
return [wrapper for i in range(request.param)]


@pytest.fixture(params=[_multicall, _legacymulticall], ids=lambda item: item.__name__)
Copy link
Member

Choose a reason for hiding this comment

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

I figure this fixture isn't really needed any more.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Lel, good point.

@@ -14,34 +14,9 @@ def MC(methods, kwargs, firstresult=False):
for method in methods:
f = HookImpl(None, "<temp>", method, method.example_impl)
hookfuncs.append(f)
if "__multicall__" in f.argnames:
caller = _legacymulticall
return caller(hookfuncs, kwargs, firstresult=firstresult)
Copy link
Member

Choose a reason for hiding this comment

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

No need for the caller indirection anymore.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Woo yeah this should be a nice cleanup 😸

"removed in an upcoming release.",
DeprecationWarning,
)
self.multicall = _legacymulticall
Copy link
Member

Choose a reason for hiding this comment

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

Probably the self.multicall indirection is not needed anymore -- can call _multicall directly?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bluetech actually, come to think of this I wonder if it makes sense to keep this in preparation for something like #50? The overloading of the multi-caller I guess can be done anywhere?

I'd like @RonnyPfannschmidt's opinion on this.

Also this might bring up discussion on whether the PluginManager._inner_hookexec is something we could also get rid of since it only seems to be used for tracing iirc. Might be better addressed in a new issue/discussion tho.

Copy link
Member

Choose a reason for hiding this comment

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

actually, come to think of this I wonder if it makes sense to keep this in preparation for something like #50?

I'd say remove it and let #50 add it back, to show the "real cost", but up to you.

Also this might bring up discussion on whether the PluginManager._inner_hookexec is something we could also get rid of since it only seems to be used for tracing iirc

pytest seems to use the tracing stuff (add_hookcall_monitoring)

Copy link
Contributor Author

@goodboy goodboy Jun 3, 2020

Choose a reason for hiding this comment

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

pytest seems to use the tracing stuff

Definitely, I've just wondered about implementing the tracing as part of the hook caller instead of some wrapper slapped in around the _hookexec() by the PluginManager.

Looking at this again I'm more convinced all that tracing magic should be implemented on the _HookCaller including adding a method to do the .subset_hook_caller() stuff. In particular it's currently limiting us from doing per-hook tracing as well.

If you want to do tracing around the caller I'm not sure why that has anything to do (abstraction wise) with the plugin manager - the only relation really is the global context of tracing all hooks that is currently supported.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bluetech either way I dropped the _HookCaller.multicall here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Made #262 regarding my 2nd last comment.

@@ -0,0 +1,2 @@
Remove internal usage of legacy ``__multicall__`` recursive hook calling system.
Copy link
Member

Choose a reason for hiding this comment

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

Unless I'm misunderstanding, this is a public API, not just internal usage, so

Suggested change
Remove internal usage of legacy ``__multicall__`` recursive hook calling system.
Remove legacy ``__multicall__`` recursive hook calling system.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bluetech actually I'm pretty sure this was always an internal system used as a hack, which is why we were also able to remove it.

I think @RonnyPfannschmidt might be able to comment since he has seniority 😼

@bluetech
Copy link
Member

bluetech commented Jun 3, 2020

One question, should I start a 1.0 tag here to get a dev version going?

I think it would be good to have pre-release versions, we can change pytest master to use them.

@goodboy
Copy link
Contributor Author

goodboy commented Jun 3, 2020

One question, should I start a 1.0 tag here to get a dev version going?

I think it would be good to have pre-release versions, we can change pytest master to use them.

Indeed @bluetech. Is a beta0 tag good enough: 1.0.beta0 as per PEP 440 or something similar maybe?

@bluetech
Copy link
Member

bluetech commented Jun 3, 2020

Is a beta0 tag good enough: 1.0.beta0 as per PEP 440 or something similar maybe?

From the link you provided, looks like it should rather be 1.0.0b1.

I think alpha or beta is appropriate (compared to the "Developmental releases" which are described as regularly occurring things).

@goodboy
Copy link
Contributor Author

goodboy commented Jun 3, 2020

@bluetech fwiw I'm pretty sure setuptools will transform 1.0.0beta0 -> 1.0.0b0.

compared to the "Developmental releases" which are described as regularly occurring things).

Plus I think setuptools_scm already uses the dev tags for rolling development releases based on the git hash.

@RonnyPfannschmidt
Copy link
Member

Setuptools_scm supports a .dev tag suffix to denote a new development epoch

@goodboy
Copy link
Contributor Author

goodboy commented Jun 3, 2020

Just waiting on what tag I should push team 😄

@RonnyPfannschmidt
Copy link
Member

i would propose 1.0.dev to be inserted on master after merge

@goodboy goodboy merged commit 016e410 into pytest-dev:master Jun 4, 2020
This was referenced Jun 4, 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.

6 participants