-
Notifications
You must be signed in to change notification settings - Fork 136
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
Unable to register extension when requiring deptrac-shim #916
Comments
If the scoper is at fault, I have to think about a good solution. Disabling it, would essentially defeat the purpose of having deptrac-shim. Maybe we can exclude Symfony contracts from scoping? |
This is probably a tricky one. We can definitely look at phpstan for inspiration. As far as I can tell, we need to be able to refer to the project's own autoloader in the depfile and then integrate it with our autoloader. |
I have read through the box and scoper documentation and from what I understood it is actually much simpler. The reason for scoping is to not clash at runtime with outside code. However this can never happen in deptrac, as:
Both NikicPHPParser and BetterReflection(possible solution to analyzing method calls) do not actually load the inspected code into the runtime, therefore there are no clashes there. If we were doing it, you could not run deptrac on itself without packaging it first, but you can. This is a perfectly working command that I use quite often to test I have not broken anything: # inside deptrac project root folder
php deptrac.php Maybe I am missing something here... |
How would we deal with conflicting dependencies? Deptrac right now depends on the v2 of composer/xdebug-handler and not v3. Therefore I could require Deptrac directly. The shim helps right now with this. How do other projects like PhpStan handle this? |
With a custom compiler and configs like these: https:/phpstan/phpstan-src/blob/1.9.x/compiler/build/scoper.inc.php. I don't think we have the manpower to replicate and maintain this effort. There are paid developers working on PhpStan, it is not a fair comparison. If you need to deal with conflicting dependencies, you can always install a PHAR version instead. |
I would prefer people use the phar archive via shim or phive rather than the src. It is mostly to prevent version conflicts between dependencies, but also avoiding issues from people who expect backwards compatibility for Deptrac classes in their vendor directory, which we don't guarantee (as noted in the docs upgrade I recently started). I really want to look into phpstan's scoper and how much work it would be to provide something similar before deciding to sunset the phar archives. |
How about adding deptrac as an executable in the main repository's composer.json, and then recommending people use https:/bamarni/composer-bin-plugin to keep the dependencies separate? To make my plugin usable I added a new bin (named deptrac-x) which calls deptrac from the main repo, allowing me to include my plugins and have an executable. See https:/ariddlestone/deptrac-extras. I can now require my package (rather than deptrac-shim) using composer-bin-plugin, and run deptrac from vendor/bin/deptrac-x. It would be nice if I didn't have to though 😉 |
The |
Also:
The text was updated successfully, but these errors were encountered: