Release 1.0?

[nicoddemus]

Hi,

As has been discussed before, is it time to start discussing about the 1.0 release? It has been in use in production in pytest, tox and devpi for some time after all.

• Do we have any major changes that are backward incompatible?
• What to do about our scheduled deprecations?

Milestone 1.0

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

[goodboy]

@nicoddemus sorry must have missed this. Yes I guess we should start working seriously towards this.

I was kind of hoping for at least the following features to be brought in before 1.0:

• support the creation fo an actual plugin dependency tree and use its root for consideration/order #51
• Have a unified way of showing info about installed plugins #87

This would lay a clean-ish slate for moving onto bigger and better ideas.
It's my bad for not being more on top of this; I've been somewhat distracted with other projects recently.

I would love to see the deprecation list finished up as well yes!
I'd be interested in setting some milestones so that we can start pushing towards this.

[RonnyPfannschmidt]

#51 is too big and complicated to get right in any kind of rush
#87 is "just a feature" and needs experimentation in any case to get the api level right (see the discussion there)

we need to reiterate introducing/removing arguments for invocations over time - i'd like to have @hpk42 as part of that discussion

[hpk42]

I haven't tracked pluggy development lately. FWIW a 1.0 sounds fine with me, it's indeed stable enough and there can always be a 1.1 and 2.0.

…

On Mon, Apr 30, 2018 at 06:47 -0700, Ronny Pfannschmidt wrote: #51 is too big and complicated to get right in any kind of rush #87 is "just a feature" and needs experimentation in any case to get the api level right (see the discussion there) we need to reiterate introducing/removing arguments for invocations over time - i'd like to have @hpk42 as part of that discussion -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #140 (comment)

[nicoddemus]

I agree with @hpk42, IMO we only need to hold a 1.0 release if we have plans for backward incompatible changes for the near feature or if there are things we should start deprecating now, otherwise new features can come in the next minor releases.

The main thing for me is that we have been using pluggy in production for years, so it is definitely production-ready.

[RonnyPfannschmidt]

i agree - thanks everyone for the input

[goodboy]

So should we move forward with the deprecation list then now or no?
I think it'd be good to get some of the cruft flushed out of the code base if at all possible - less is more some say :)

[nicoddemus]

By deprecation list you mean deprecation ?

• Deprecate (and eventually remove) implprefix support #116 Deprecate (and remove) implprefix support - pytest can't really live without this, so as we discussed we should implement it into PytestPluginManager and remove it from pluggy.
• Remove __multicall__ support #59 Remove multicall support - This has been deprecated for a few years now and I think there are very few (if any) pytest plugins which still use this. I think it is fair to remove it altogether.
• Change call_historic callback kwarg name #120 Change call_historic callback kwarg name: not sure what's the real impact here from the POV of pytest.

[goodboy]

@nicoddemus @RonnyPfannschmidt so sorry I've let this slide.

So what's the consensus?
Stick with just the deprecation list for now?

[RonnyPfannschmidt]

yeah

[nicoddemus]

Before deprecating the impl-prefix support, we should port it over to pytest; every pytest plugin uses it, so it wouldn't be helpful to release a pluggy version which issues warnings for its usage.

[bluetech]

Since Python 2 is now officially no longer supported, perhaps pluggy 1.0 can be Python3-only?

pytest is 3-only, so it's not a problem for it. Not sure about other pluggy users, but Python 2 users will continue to get the 0.13.x version so it's not that they'll stop working.

[goodboy]

For those watching, this is our current milestone list which is totally up for being modified.

[goodboy]

Oh, I was also going to ask should be start a 1.0 candidate git branch?

Might be useful if we get multiple contributors nailing down the milestone list concurrently.
I'm also cool with just merging to master and delaying an official release; I'm just wondering if there's anything we want to sweep in before officially dropping python2.

[goodboy]

Ok I'm putting up a tag on master on the history pinned at the merge commit for #147.

[bluetech]

We are planning to release pytest 6.0 soon, and it will be nice to be able to depend on pluggy>=1,<2.

Here are the remaining items from my POV:

• Merge Validate that a hookwrapper's function is a generator function during registration #282 "Validate that a hookwrapper's function is a generator function during registration" -- needs a major version bump per @RonnyPfannschmidt's comment.

• Merge hookwrappers can't modify the in-flight exception without skipping later hookwrapper teardowns #244 "Handle exceptions in hookwrapper post stage" -- needs a major version.

• Implement return values from hookwrappers -- I think we should do this as explained in last part of this comment. I will prepare a PR for this after/if hookwrappers can't modify the in-flight exception without skipping later hookwrapper teardowns #244 is merged. Technically also a breaking change so needs a major bump.

• Release a release candidate, update pytest to it, make sure everything's fine (note that pytest CI already regularly checks pluggy master).

• Release the final 1.0.0.

I think the other items on the 1.0 milestone don't need a breaking change:

• deprecate load_setuptools_entrypoints -- deprecation can still in a minor version as well.

• iterable hooks -- a new feature, I don't think it needs any breaking changes.

• have a unified way of showing info about installed plugins -- probably can be backward compatible?

• add some benchmark tests -- probably shouldn't block a release, but I can work on it if it's necessary.

WDYT? If this is too much we can definitely stick with 0.13 for pytest 6.0.

[RonnyPfannschmidt]

the unification and the setuptools entrypoint details will require some breaking change to acoud the accumulation of cruft

we should take a look at what integration layer could be used there (in particular to enable steam-less changes in combination with tox, pytest, devpi and a few more users

the rest i agree with

[bluetech]

@RonnyPfannschmidt what I meant was more that any changes there would require a deprecation period, so the breaking changes can't be done for 1.0.0 itself (the next release). But adding a deprecation can happen also after 1.0.0 is released, so I think it shouldn't block it.

[goodboy]

@bluetech sorry I've been absent.

Cursory look says your list looks good to me.

Btw for anyone looking for the milestone list (in case you missed it in my prior comment) I've also stuck it in the description.

I'm trying to wrap up a big piece of something new I'm working on.
Once that's done I'll go through all these out-standings in detail.

[ashwoods]

I have been prototyping pluggy in a small project I am working on, and as a result looking into pluggy in general. There might be one feature #151 you might look into before a 1.0 release. Having a asyncio compatible design (at least on paper) before signalling any kind of API stability might save you from some headaches.

[adriendelsalle]

Hey! Thanks for this project!
Any chance that the 1.0.0.dev0 released now more than 1.5yr ago become the official 1.0.0 soon?

Thanks!

[adriendelsalle]

ping @nicoddemus

[nicoddemus]

@RonnyPfannschmidt @goodboy @bluetech we have still some issues but none of them seems to be a blocker for 1.0 (#154 doesn't even seem doable in a reasonable time frame either):

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

Any objections with going ahead and making 1.0.0?

[bluetech]

My plan was #140 (comment), but PR #244 didn't get any approvals besides my own, and got stuck. I think it would be good to release 1.0 in the current state and consider the rest of the plan for a 2.0, than to wait any more.

[goodboy]

Any objections with going ahead and making 1.0.0

None from I.
I don't have as much bandwidth these days to focus on pushing out features here unfortunately.

If peeps want scrappier / more frequent releasing I have no qualms with it; more then happy to review and fix things where needed 😎

[adriendelsalle]

Looks good! I can also help you to finish some work if you need, don't hesitate to ping me!

[adriendelsalle]

@nicoddemus do you have any idea about when it could be achieved?
Thx!

[nicoddemus]

Hi @adriendelsalle,

Thanks for the ping.

I'm under the impression that #326 was meant for 1.0, but I might be wrong (and just realized it is not actually in the 1.0 milestone).

@RonnyPfannschmidt what do you think?

[RonnyPfannschmidt]

its not planned for 1.0 - last week i simply had a small sprint to get pluggy faster by cython/mypyc and some refactorings
while i learned a lot about cython/mypyc and the related issues, its not a blocker and currently on hold until i get more time (likely friday)

[nicoddemus]

Ahh OK, thanks for the clarification!

I will kick off the release later today then. 👍

[nicoddemus]

1.0.0 is out. 🎉

Thanks everyone who participated.

[hoefling]

Since you're all pytest devs as well, I might just ask it here. What's the next step regarding pytest? I'm anxious for bumping pluggy, but all our projects use pytest for testing (some of them are actually pytest plugins). So until pytest allows installing pluggy==1.0.0, I can only look, but not touch 😊

[nicoddemus]

@hoefling pytest 7.0 should support pluggy 1.0 or later (actually it does support already, we will just update the version pinning: pytest-dev/pytest#9040).

[hoefling]

@nicoddemus awesome, thanks! Once pytest-dev/pytest#9040 is merged, I can test things out with pytest git dependency until 7.0 is out.