Skip to content

Modernize varnames function #27

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 2 commits into from
Nov 11, 2016
Merged

Modernize varnames function #27

merged 2 commits into from
Nov 11, 2016

Conversation

goodboy
Copy link
Contributor

@goodboy goodboy commented Nov 11, 2016

As per #19 this provides an update to pluggy.varnames().
I've successfully run the unit tests across all interpreters on arch linux.
I'd like to test this across all dependent projects (pytest, tox, etc.) as well (and eventually get those tests integrated in a travis job for this project).

Note we'll need to move to inspect.signature() for py3.6...

Tyler Goodlet added 2 commits August 26, 2016 19:59
Currently if you instantiate class which defines hook specs the
introspector (`pluggy.varnames`) breaks on methods and incorrectly
returns the `self` name. I found this by accident. Although it would be
odd it's still conceivable that a user might wish to define hook specs
on an instance. The real problem seems to be that varnames doesn't
actually disregard `self` like the doc string claims.
Delegate to inspect for for the argument spec and remove the need for
the `startindex` kwarg. Avoid inspecting raw code and bring the
'self' check assert into this function. This also adds support for
hookspecs defined on instances.

Resolves pytest-dev#19
return ()
if startindex is None:
startindex = int(inspect.ismethod(func))
elif not inspect.isroutine(func): # callable object?
Copy link
Member

Choose a reason for hiding this comment

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

since what version of python does that method exist?

Copy link
Member

Choose a reason for hiding this comment

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

never mind, i just verified its in 2.6

Copy link
Member

@RonnyPfannschmidt RonnyPfannschmidt left a comment

Choose a reason for hiding this comment

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

i quite like this, it took a moment to realize that this allows compact setups where specs can ship default implementations along

@hpk42
Copy link
Contributor

hpk42 commented Nov 11, 2016

I also like it -- @tgoodlet did you get a chance to test this against tox, pytest yet? i guess doing develop installs from all of pluggy, pytest, tox and then running the respective test suites would go a long way. Maybe pytest is not so imnportant actually because pluggy's test suite uses it and pytest will in turn use the latest pluggy and pytest is by far the heaviest user of pluggy i guess. So i am merging this but i'd welcome if you watch this repository here in case related bugs turn up later.

@hpk42 hpk42 merged commit c883d1f into pytest-dev:master Nov 11, 2016
@nicoddemus
Copy link
Member

... pytest will in turn use the latest pluggy and pytest is by far the heaviest user of pluggy i guess

Actually we vendor pluggy in pytest, so pytest itself won't be using the local pluggy.

@hpk42
Copy link
Contributor

hpk42 commented Nov 11, 2016

On Fri, Nov 11, 2016 at 07:05 -0800, Bruno Oliveira wrote:

... pytest will in turn use the latest pluggy and pytest is by far the heaviest user of pluggy i guess

Actually we vendor pluggy in pytest, so pytest itself won't be using the local pluggy.

good point.

@goodboy
Copy link
Contributor Author

goodboy commented Nov 11, 2016

@hpk42 @nicoddemus @RonnyPfannschmidt that's one thing I tried to bring up before (pytest-dev/pytest#1637). I REALLY think in order to promote active development of pluggy pytest should be reversing it's import logic for the vendored versus locally installed pluggy version. If we start doing pluggy CI that includes running the test suites for dependent projects it makes it much easier to manage as well.

@nicoddemus had made the comment in that discussion:

I think the point of vendoring is to isolate different pluggy installations in the same environment. For example, I right now both pytest and tox use pluggy in some vendored version, so different (and incompatible) versions of pluggy can coexist in the same virtual environment without problems.

I feel like this only applies to the case where you're running pytest to test tox (unless I'm missing something) since when running tox you should never be sharing pluggy with the underlying virtualenvs anyway. In other words there should never be a case where pytest and tox must share the same pluggy version under normal tox usage.

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.

4 participants