[Finder] Deprecate adapters and related classes #15805

nicolas-grekas · 2015-09-15T13:41:00Z

Q	A
Bug fix?	no
New feature?	no
BC breaks?	no
Deprecations?	yes
Tests pass?	yes
Fixed tickets	-
License	MIT
Doc PR	-

stof · 2015-09-15T13:46:07Z

src/Symfony/Component/Finder/Tests/AbstractFinderTest.php

@@ -282,7 +284,7 @@ public function testFilter($adapter)
    public function testFollowLinks($adapter)
    {
        if ('\\' == DIRECTORY_SEPARATOR) {
-            return;
+            $this->markTestSkipped('symlinks are not supported on Windows');


this should be done in older branches

stof · 2015-09-15T13:51:05Z

I suggest doing the change of the way adapters are covered in the 2.3 branch instead:

this would mark tests for other adapters as skipped instead of deleting the tests entirely, which gives feedback on the fact that some tests are not running
this would simplify the merging of branches

Tests which don't use the adapter data providers currently should also stay in a separate FinderTest instead of running several times (once per adapter testcase)

stof · 2015-09-15T13:53:18Z

src/Symfony/Component/Finder/Tests/BsdFinderTest.php

+            $this->markTestSkipped(get_class($this).' is not supported.');
+        }
+
+        return array($adapter);


Instead of a method returning an array of adapters with a single element, and then using this to build a dataProvider providing the adapter, I suggest you to use a protected method getAdapter returning the adapter being used for tests and using it in buildFinder() (which would not need an argument anymore). It would make tests much easier to understand

stof · 2015-09-15T13:58:19Z

btw, the change in the way tests for unsupported adapters are ignored is something I wanted to do after looking at the finder testsuite today while reviewing your other PR. Knowing what is running or no is hard in the current setup

nicolas-grekas · 2015-09-15T14:02:21Z

@stof would you like to do the PR on 2.3 then?

stof · 2015-09-15T14:02:48Z

Regarding the deprecation, should we actually deprecate it yet ? the comparison in #15802 (comment) still shows a significant difference between them, which means this introduces a potential slowdown for people using useBestAdapter when using the finder.

stof · 2015-09-15T14:03:06Z

@nicolas-grekas not immediately, but I can, yes.

fabpot · 2015-09-15T14:21:12Z

I think we should deprecate the other adapter for several reasons:

we now know that the PHP adapter can be fast enough;
the other adapters are fragile;
removing this code is something I wanted to do since ages :).

stof · 2015-09-15T14:23:45Z

btw, the finder-benchmark has a bunch of other cases which have not been run when you compared it (they are commented in the latest commit of the finder benchmark repo but you can uncomment it). It would be great to run them too.

@fabpot we know we can optimize the PHP adapter further. but shouldn't we do it before deprecating things ? useBestAdapter will now use the php adapter all the time unless people register the deprecated adapters explicitly.

Btw, if we deprecate adapters, we should also deprecate adapter-related methods in the Finder class

fabpot · 2015-09-15T14:35:27Z

I'm all for removing everything related to the adapters in the Finder. I wouldn't want this code in 3.0 if possible. It was a mistake back then to introduce such a complex layer.

nicolas-grekas · 2015-09-15T14:36:08Z

From what I understand by reading quickly the code, the Gnu and Bsd adapters are never used by default. The only way to use them is to enabled them explicitly. Which means almost everyone uses the PhpAdapter. I'd be in favor of deprecating to have 3.0 cleaned from them.
OK for removing all the adapter layer on my side.

stof · 2015-09-15T14:37:43Z

@nicolas-grekas they would be used when using useBestAdapter().

Note that I fully agree with you about the need to deprecate it and clean it. The question is whether we should work on optimization first or no.

nicolas-grekas · 2015-09-15T14:47:39Z

Given that the feature freeze is in a few days, I'd be in favor of deprecating now, and optimize later

nicolas-grekas · 2015-09-15T16:20:20Z

Status: needs work
To be rebased on top of #15808

stof · 2015-09-15T16:47:38Z

should we reopen #5951 until more optimization work is done ?

@nicolas-grekas

This PR was merged into the 2.3 branch. Discussion ---------- Improve the structure of the Finder testsuite | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | n/a | License | MIT | Doc PR | n/a Testing against different adapters is now handled by multiple subclasses of a common test case rather than using data providers. This allows tests to be marked as skipped for unsupported adapters instead of making them disappear from the testsuite. This will also make it much easier to mark tests for the find-based adapters as legacy ones when deprecating them. This correspond to changes done by @nicolas-grekas in #15805, backported to 2.3 and with the data providers removed (his PR was keeping data providers for the adapter but making it return a single adapter all the time, hence the much bigger diff in my PR). All tests in AbstractFinderTest are just moved from the FinderTest (they are all the tests running against multiple adapters). FinderTest itself runs the PhpAdapter (as this is the logic we want to keep in the finder in 3.0). I also tried to have a PhpFinderTest and keeping FinderTest only with the extra tests, but this would make things harder to merge branches between 2.8 and 3.0 in the future (once we remove other adapter tests) as we could simply keep the AbstractFinderTest in 3.0 for now to ease merging PRs adding new tests for bug fixes. Commits ------- 20f2d03 Improve the structure of the Finder testsuite

stof · 2015-09-16T09:26:16Z

@nicolas-grekas you can now work again on this (after merging branches together)

nicolas-grekas · 2015-09-18T07:57:26Z

PR updated with all the adapter layer being deprecated.

stof · 2015-09-18T08:11:39Z

src/Symfony/Component/Finder/Finder.php

+            $iterator = $iteratorAggregate->getIterator();
+        }
+
+        return $iterator;


We should find a way to avoid duplicating the PhpAdapter codebase. It would be a maintenance pain otherwise as we would have to think about duplicating any change when merging branches into 2.8

I thought the same at first, but this would require some indirection that would be just boilerplate for the shake of synchronization.
Instead, I propose to add a test (here) that just checks that the source code is kept in sync.
Given that all 2.x branches are going to be moved to maintenance only mode, this code won't move that much now.
I think this new test + the test suite is enough as a safe guard. Don't you?

@nicolas-grekas given that Finder optimization are currently considered as being suited for maintenance releases, it might still change :)
but yeah, the test is a good idea.

nicolas-grekas · 2015-09-18T08:12:25Z

Status: needs review

stof · 2015-09-18T09:00:03Z

src/Symfony/Component/Finder/Finder.php

@@ -771,11 +792,7 @@ private function sortAdapters()
    }

    /**
-     * @param $dir


the param should be kept (but we should add the missing type in a 2.3+ PR)

that's a private function...

but ok, reverted

stof · 2015-09-18T09:02:23Z

👍

Status: reviewed

fabpot · 2015-09-22T11:58:36Z

Thank you @nicolas-grekas.

…as-grekas) This PR was merged into the 2.8 branch. Discussion ---------- [Finder] Deprecate adapters and related classes | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | yes | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - Commits ------- c08cf4b [Finder] Deprecate adapters and related classes

This PR was merged into the 3.3-dev branch. Discussion ---------- [Finder] Deprecate ExceptionInterface | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | yes | Tests pass? | yes | Fixed tickets | N/A | License | MIT | Doc PR | N/A This interface was missed in #15805, and should have been removed in 3.0. Ideally, the component should have such an interface, though, as other components does. But the only domain exception in this component is an `AccessDeniedException` used by the `RecursiveDirectoryIterator`. So it isn't worth it right now. I think this interface was almost internal actually, but anyway the `\Symfony\Component\Finder\Adapter\AdapterInterface` interface does not exist anymore. So the `ExceptionInterface::getAdapter()` signature cannot be satisfied anyway. I guess anyone relying on this interface in any way should have notice that and removed anything related to Symfony Finder's adapters when upgrading to 3.0. Should we consider removing it directly in the 3.1 branch instead? Commits ------- 1b600b0 [Finder] Deprecate ExceptionInterface

@nicolas-grekas

This PR was merged into the 2.3 branch. Discussion ---------- Improve the structure of the Finder testsuite | Q | A | ------------- | --- | Bug fix? | no | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | n/a | License | MIT | Doc PR | n/a Testing against different adapters is now handled by multiple subclasses of a common test case rather than using data providers. This allows tests to be marked as skipped for unsupported adapters instead of making them disappear from the testsuite. This will also make it much easier to mark tests for the find-based adapters as legacy ones when deprecating them. This correspond to changes done by @nicolas-grekas in symfony/symfony#15805, backported to 2.3 and with the data providers removed (his PR was keeping data providers for the adapter but making it return a single adapter all the time, hence the much bigger diff in my PR). All tests in AbstractFinderTest are just moved from the FinderTest (they are all the tests running against multiple adapters). FinderTest itself runs the PhpAdapter (as this is the logic we want to keep in the finder in 3.0). I also tried to have a PhpFinderTest and keeping FinderTest only with the extra tests, but this would make things harder to merge branches between 2.8 and 3.0 in the future (once we remove other adapter tests) as we could simply keep the AbstractFinderTest in 3.0 for now to ease merging PRs adding new tests for bug fixes. Commits ------- 12f0f55 Improve the structure of the Finder testsuite

carsonbot added the Status: Needs Review label Sep 15, 2015

nicolas-grekas force-pushed the deprec-adapters branch 2 times, most recently from c86cf65 to 473330c Compare September 15, 2015 13:43

stof reviewed Sep 15, 2015
View reviewed changes

stof mentioned this pull request Sep 15, 2015

Improve the structure of the Finder testsuite #15808

Merged

nicolas-grekas force-pushed the deprec-adapters branch 2 times, most recently from f758dd8 to 0163796 Compare September 15, 2015 16:19

carsonbot added Status: Needs Work and removed Status: Needs Review labels Sep 15, 2015

nicolas-grekas force-pushed the deprec-adapters branch 2 times, most recently from a0002a7 to 55fb6b3 Compare September 18, 2015 07:56

nicolas-grekas changed the title ~~[Finder] Deprecate find based adapters~~ [Finder] Deprecate adapters and related classes Sep 18, 2015

nicolas-grekas force-pushed the deprec-adapters branch from 55fb6b3 to 58b6c29 Compare September 18, 2015 08:10

stof reviewed Sep 18, 2015
View reviewed changes

carsonbot added Status: Needs Review and removed Status: Needs Work labels Sep 18, 2015

nicolas-grekas force-pushed the deprec-adapters branch from 58b6c29 to d243913 Compare September 18, 2015 08:29

stof reviewed Sep 18, 2015
View reviewed changes

carsonbot added Status: Reviewed and removed Status: Needs Review labels Sep 18, 2015

[Finder] Deprecate adapters and related classes

c08cf4b

nicolas-grekas force-pushed the deprec-adapters branch from d243913 to c08cf4b Compare September 18, 2015 09:02

nicolas-grekas added the Ready label Sep 18, 2015

fabpot merged commit c08cf4b into symfony:2.8 Sep 22, 2015

nicolas-grekas deleted the deprec-adapters branch September 22, 2015 13:39

fabpot mentioned this pull request Nov 16, 2015

Release v2.8.0-BETA1 #16550

Merged

ogizanagi mentioned this pull request Dec 12, 2016

[Finder] Deprecate ExceptionInterface #20884

Merged

staabm mentioned this pull request Jun 12, 2017

Exclude directory paths from file system search felixfbecker/php-language-server#401

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Finder] Deprecate adapters and related classes #15805

[Finder] Deprecate adapters and related classes #15805

nicolas-grekas commented Sep 15, 2015

stof Sep 15, 2015

stof commented Sep 15, 2015

stof Sep 15, 2015

stof commented Sep 15, 2015

nicolas-grekas commented Sep 15, 2015

stof commented Sep 15, 2015

stof commented Sep 15, 2015

fabpot commented Sep 15, 2015

stof commented Sep 15, 2015

fabpot commented Sep 15, 2015

nicolas-grekas commented Sep 15, 2015

stof commented Sep 15, 2015

nicolas-grekas commented Sep 15, 2015

nicolas-grekas commented Sep 15, 2015

stof commented Sep 15, 2015

stof commented Sep 16, 2015

nicolas-grekas commented Sep 18, 2015

stof Sep 18, 2015

nicolas-grekas Sep 18, 2015

stof Sep 18, 2015

nicolas-grekas commented Sep 18, 2015

stof Sep 18, 2015

nicolas-grekas Sep 18, 2015

nicolas-grekas Sep 18, 2015

stof commented Sep 18, 2015

fabpot commented Sep 22, 2015

[Finder] Deprecate adapters and related classes #15805

[Finder] Deprecate adapters and related classes #15805

Conversation

nicolas-grekas commented Sep 15, 2015

Choose a reason for hiding this comment

stof commented Sep 15, 2015

Choose a reason for hiding this comment

stof commented Sep 15, 2015

nicolas-grekas commented Sep 15, 2015

stof commented Sep 15, 2015

stof commented Sep 15, 2015

fabpot commented Sep 15, 2015

stof commented Sep 15, 2015

fabpot commented Sep 15, 2015

nicolas-grekas commented Sep 15, 2015

stof commented Sep 15, 2015

nicolas-grekas commented Sep 15, 2015

nicolas-grekas commented Sep 15, 2015

stof commented Sep 15, 2015

stof commented Sep 16, 2015

nicolas-grekas commented Sep 18, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nicolas-grekas commented Sep 18, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stof commented Sep 18, 2015

fabpot commented Sep 22, 2015