Vendor new pluggy version

[nicoddemus]

As suggested in #704

[blueyed]

This needs a new release of pluggy first, which @hpk42 and me got distracted from doing at the end of the sprint.

[nicoddemus]

@hpk42 and @blueyed, any chance of doing a 0.3.2 release this week? Should we postpone this to 3.1?

[blueyed]

@nicoddemus
Only @hpk42 seems to be able to do it.
It's not really critical for 3.0 (AFAIK), but would be really nice to have finally.
(I was running into the VersionConflict traceback yesterday again, where you cannot see where it's coming from with the current pluggy release - very annoying).

[RonnyPfannschmidt]

i mailed @hpk42 about moving it to pytest-dev and adding more if pytest-core to the pypi maintainers

[nicoddemus]

As @hpk42 is on vacation, I'm moving this to 3.1 as I don't think it should block the 3.0 release.

[The-Compiler]

Couldn't we just vendor the current git state FWIW?

[nicoddemus]

Not sure it's a good idea... currently we show pluggy's version on pytest's output, so it would be weird to display a hash at that point...

[The-Compiler]

Fair enough - let's postpone it to 3.1 then.

[The-Compiler]

From the ML:

Ronny asked me to move the pluggy (pluginmanager used by pytest, devpi, tox, others) repo to pytest-dev organisation and i just did it. It's now at:

https://github.com/pytest-dev/pluggy

Also added the same people to the pluggy pypi page who can release pytest.

cheers,
holger

[goodboy]

Nice pluggy is in :)

I've been meaning to suggest reversed import logic in _pytest.pluggy; why not try to import a local install of pluggy and then fail over to the vendor-ed version?
It makes hacking on pluggy / running the pytest test suite against it a lot easier.

[nicoddemus]

why not try to import a local install of pluggy and then fail over to the vendor-ed version?

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.

Hope that's clear, gotta go sleep in... like two hours ago already. 😬

[goodboy]

@nicoddemus ahh gotcha. That use case didn't even cross my mind.

I guess it seems odd to me because when would you ever not have your local vendored version? It's not like it makes any difference right now if you decide to install a dev version of pluggy alongside these projects inside a venv because that version won't be used unless you manually modify the import logic.

Further, maybe the more correct solution is to get pluggy working across both packages?

[RonnyPfannschmidt]

@tgoodlet bascially the exact pluggy api is supposed to be a implementation detail of tox/pytest that does not leak

however the python module system makes such an abstraction impossible, thus we separate with way more crude mechanisms

[nicoddemus]

Further, maybe the more correct solution is to get pluggy working across both packages?

That's the plan for pluggy-1.0. Meanwhile the plan is to vendor it in pytest and tox, at least.

[blueyed]

Finally! 🎆
Thanks!

[nicoddemus]

😁