[PhpUnitBridge] Always segregate vendor and non vendor deprecations #27006

greg0ire · 2018-04-22T17:18:11Z

Q	A
Branch?	master
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes
License	MIT
Doc PR	I don't think it warrants one

Even if it does not make the exit code change, this is valuable
information. Besides, not doing this reduces the complexity (fewer tests
for the weak vendors mode).
I introduced a new closure for computing whether the build is failing or
not, named using positive logic so that things are easier to understand.

javiereguiluz · 2018-04-22T17:21:58Z

@greg0ire is this related to #26972 or could help us implement that idea? Thanks!

greg0ire · 2018-04-22T17:57:10Z

It is slightly related, and it is a step towards a second attempt at doing #24867, which is deeply related, and might help you implement that idea.

greg0ire · 2018-04-22T18:02:19Z

To sum things up, there is vendor code code and your code. This PR makes the distinction between your code calling your deprecated code , and your code calling deprecated vendor code. #24867 is about a third category: vendor code calling deprecated vendor code.

alcaeus · 2018-05-23T04:52:06Z

src/Symfony/Bridge/PhpUnit/DeprecationErrorHandler.php


                // store failing status
-                $isFailing = DeprecationErrorHandler::MODE_WEAK !== $mode && $mode < $deprecations['unsilencedCount'] + $deprecations['remainingCount'] + $deprecations['otherCount'];
+                $passesBeforeShutdown = !$isPassing($mode, $deprecations);


I believe the negation is incorrect: let's assume $isPassing returns true here and in the shutdown function below. $passesBeforeShutdown will be false, which causes the if on line 275 to evaluate to true and exit with a non-zero exit code.

Oh right! Probably something I forgot to change when I decided to avoid negative logic 👍

nicolas-grekas · 2018-07-23T20:16:39Z

I don't think this segregation makes sense: your code is always the root of any calls made to vendors.
Take e.g. Yaml deprecations: you write the yaml config or call the parser, and the Yaml component calls the code that triggers deprecations, leading to false-negatives.
I'm 👎 with this reasoning.

greg0ire · 2018-07-23T20:29:47Z

your code is always the root of any calls made to vendors.

It very much is, but you can get deprecations without any calls made to your vendors, and if you do, that's probably the deprecations that should be fixed in priority, especially when you are a library, because it means you are calling your own code in a deprecated way

nicolas-grekas · 2018-07-23T20:43:14Z

Maybe it's a matter of vocabulary: vendor vs not-vendor means little to me as I explained, but direct vs indirect makes more sense to me.

greg0ire · 2018-07-23T21:32:25Z

This is not a segregation between direct and indirect, it's a segregation between src -> src and (src -> vendor or vendor -> vendor), or, as you'd call it, between internal and (direct or indirect, but vendor)

nicolas-grekas · 2018-07-25T13:12:33Z

According to #28048, it could make sense to group deprecations in 3 groups (in this order):

in app (=triggered in src/)
calling vendors (=direct deprecations when src/ calls something in vendors/)
remaining (=indirect deprecations, e.g. related to config/)

Maybe also implement the thresholds discussed in #28048 here?
A screenshot would help btw at some point :)

greg0ire · 2018-07-25T15:00:36Z

I can do all this, but to be clear, the segregation already exists, it is just that it is restricted to the weak_vendors mode only, and this PR lifts that restriction.

Here is how it looks right now:

stof · 2018-07-25T15:54:43Z

fewer tests for the weak vendors mode, which I plan to replace with different exit codes

you cannot replace the mode by something switching the exit code. any non-0 exit code is a failure, and CI would break on them. Having to replace the weak_vendor mode by a wrapper command checking the return type to make it 0 in some cases would be bad DX.

greg0ire · 2018-07-25T20:16:54Z

Another idea could be to produce a report in an easy-to-parse format and let people act on it if they wish to.

nicolas-grekas · 2018-07-25T22:09:03Z

Unless someone needs that IRL and is willing to implement, that possible, but we're not looking for more code to maintain à priori. :)

greg0ire · 2018-07-26T06:47:18Z

Rebased without the comment about exit codes

fabpot · 2018-10-10T11:23:37Z

@greg0ire @nicolas-grekas How do we move forward on this one?

greg0ire · 2018-10-10T11:55:56Z

I'm currently working on an implementation of #28048 , and it would make my life easier if this got merge, so I'm going to rebase this again, and hope you accept to merge it.

Even if it does not make the exit code change, this is valuable information. Besides, not doing this reduces the complexity (fewer tests for the weak vendors mode). I introduced a new closure for computing whether the build is failing or not, named using positive logic so that things are easier to understand.

nicolas-grekas · 2018-10-10T12:01:19Z

I'd suggest borrowing this PR is your work.
It cannot be merged as is to me.

greg0ire · 2018-10-10T12:02:19Z

Ok

carsonbot added Status: Needs Review Feature labels Apr 22, 2018

greg0ire force-pushed the always_segregate_vendors_and_non_vendor_deprecations branch from 2f59a4a to caf8e6b Compare April 22, 2018 17:18

nicolas-grekas changed the title ~~Always segregate vendor and non vendor deprecations~~ [PhpUnitBridge] Always segregate vendor and non vendor deprecations Apr 22, 2018

nicolas-grekas added this to the next milestone Apr 24, 2018

carsonbot removed the Status: Needs Review label May 23, 2018

alcaeus suggested changes May 23, 2018

View reviewed changes

carsonbot added the Status: Needs Work label May 23, 2018

greg0ire force-pushed the always_segregate_vendors_and_non_vendor_deprecations branch from caf8e6b to 18acc34 Compare May 23, 2018 05:38

chalasr added Status: Needs Review PhpUnitBridge and removed Status: Needs Work labels Jul 14, 2018

nicolas-grekas mentioned this pull request Jul 23, 2018

[PhpUnitBridge] make "numbered" deprecation mode count only vendor deprecations #28048

Closed

greg0ire force-pushed the always_segregate_vendors_and_non_vendor_deprecations branch from 18acc34 to 66ee0ff Compare July 26, 2018 06:46

greg0ire force-pushed the always_segregate_vendors_and_non_vendor_deprecations branch from f0c680a to f183d99 Compare October 10, 2018 11:57

greg0ire force-pushed the always_segregate_vendors_and_non_vendor_deprecations branch from f183d99 to 85c4243 Compare October 10, 2018 11:59

greg0ire closed this Oct 10, 2018

greg0ire deleted the always_segregate_vendors_and_non_vendor_deprecations branch October 10, 2018 12:02

nicolas-grekas modified the milestones: next, 4.2 Nov 1, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[PhpUnitBridge] Always segregate vendor and non vendor deprecations #27006

[PhpUnitBridge] Always segregate vendor and non vendor deprecations #27006

greg0ire commented Apr 22, 2018 •

edited

Loading

javiereguiluz commented Apr 22, 2018 •

edited

Loading

greg0ire commented Apr 22, 2018 •

edited

Loading

greg0ire commented Apr 22, 2018

alcaeus May 23, 2018

greg0ire May 23, 2018

nicolas-grekas commented Jul 23, 2018 •

edited

Loading

greg0ire commented Jul 23, 2018 •

edited

Loading

nicolas-grekas commented Jul 23, 2018

greg0ire commented Jul 23, 2018

nicolas-grekas commented Jul 25, 2018

greg0ire commented Jul 25, 2018

stof commented Jul 25, 2018

greg0ire commented Jul 25, 2018 •

edited

Loading

nicolas-grekas commented Jul 25, 2018

greg0ire commented Jul 26, 2018

fabpot commented Oct 10, 2018

greg0ire commented Oct 10, 2018

nicolas-grekas commented Oct 10, 2018 •

edited

Loading

greg0ire commented Oct 10, 2018

[PhpUnitBridge] Always segregate vendor and non vendor deprecations #27006

[PhpUnitBridge] Always segregate vendor and non vendor deprecations #27006

Conversation

greg0ire commented Apr 22, 2018 • edited Loading

javiereguiluz commented Apr 22, 2018 • edited Loading

greg0ire commented Apr 22, 2018 • edited Loading

greg0ire commented Apr 22, 2018

alcaeus May 23, 2018

Choose a reason for hiding this comment

greg0ire May 23, 2018

Choose a reason for hiding this comment

nicolas-grekas commented Jul 23, 2018 • edited Loading

greg0ire commented Jul 23, 2018 • edited Loading

nicolas-grekas commented Jul 23, 2018

greg0ire commented Jul 23, 2018

nicolas-grekas commented Jul 25, 2018

greg0ire commented Jul 25, 2018

stof commented Jul 25, 2018

greg0ire commented Jul 25, 2018 • edited Loading

nicolas-grekas commented Jul 25, 2018

greg0ire commented Jul 26, 2018

fabpot commented Oct 10, 2018

greg0ire commented Oct 10, 2018

nicolas-grekas commented Oct 10, 2018 • edited Loading

greg0ire commented Oct 10, 2018

greg0ire commented Apr 22, 2018 •

edited

Loading

javiereguiluz commented Apr 22, 2018 •

edited

Loading

greg0ire commented Apr 22, 2018 •

edited

Loading

nicolas-grekas commented Jul 23, 2018 •

edited

Loading

greg0ire commented Jul 23, 2018 •

edited

Loading

greg0ire commented Jul 25, 2018 •

edited

Loading

nicolas-grekas commented Oct 10, 2018 •

edited

Loading