That is the "problem" with PHARs. They are great for standalone tools. But as soon as you need plugins, dependencies or whatever, you get either into a lot of trouble or .. let's not discuss the OR...
@heiglandreas @sven Right now, I'm leaning towards using Phive to install PHPUnit, PHP CS Fixer, PHPStan. And using a separate composer.json for Rector, which may install PHPStan, but that will only be for Rector, I'd use the PHAR for actually running PHPStan.
@sven Depending on how Rector calls PHPStan you can even use the `replace` config inside the composer.json to make it not install PHPStan and then use PHPStan from the tools-directory...
I feel you. There's always one piece of the puzzle that does not work the I want things to work which then makes my whole idea pointless /cc @heiglandreas
I guess there is none, as rector package is delivered as a shim only requiring a specific phpstan version: https://packagist.org/packages/rector/rector So it already is like a phar shipped as composer package in some way.
@danielsiepmann but that's the thing: we're doing a lot of upgrades right now, and dependency-issues are the biggest problem we run into. mostly issues with dependencies of dev-tools. so I was hoping to put all QA/analysis tools as PHARs to minimize those issues. Everything is a PHAR, but not rector. and that requires PHPStan again. Opening up the issues again.
Senior Rabbit-Hole Explorer
in reply to Skoop (Stefan Koopmanschap) • • •Skoop (Stefan Koopmanschap)
in reply to Senior Rabbit-Hole Explorer • • •Senior Rabbit-Hole Explorer
in reply to Skoop (Stefan Koopmanschap) • • •Senior Rabbit-Hole Explorer
in reply to Senior Rabbit-Hole Explorer • • •The biggest hinderer for PHARs is IMO the "let's just use dev-dependencies in composer" attitude...
And opinions.
Senior Rabbit-Hole Explorer
in reply to Senior Rabbit-Hole Explorer • • •Sven
in reply to Senior Rabbit-Hole Explorer • • •Senior Rabbit-Hole Explorer
in reply to Sven • • •@sven It shouldn't be. As it's even more complex than having to use a different tool.
But in times of developers not being capable of using 2 different tools for 2 different things it looks like it's the way people go.
It's not DRY, it's using wrong abstractiosn. But .... 🤷
/cc @Skoop
Skoop (Stefan Koopmanschap)
in reply to Senior Rabbit-Hole Explorer • • •Senior Rabbit-Hole Explorer
in reply to Skoop (Stefan Koopmanschap) • • •@sven Depending on how Rector calls PHPStan you can even use the `replace` config inside the composer.json to make it not install PHPStan and then use PHPStan from the tools-directory...
roughly speaking...
Arne Blankerts
in reply to Skoop (Stefan Koopmanschap) • • •@heiglandreas @sven Why not talk to Thomas about it? :)
If we need to enhance phive to support this, I can do that..
Skoop (Stefan Koopmanschap)
in reply to Arne Blankerts • • •@theseer @heiglandreas @sven I could try. Although someone tried before: https://friendica.daniel-siepmann.de/display/3db7c7b4-1266-389e-e385-7af387595930
Daniel Siepmann
2024-05-06 09:12:03
Arne Blankerts
in reply to Skoop (Stefan Koopmanschap) • • •@heiglandreas @sven Okay, that's a lame excuse he wrote there, tbh.
There is no need to "manually update files".
We could also consider creating a phar-io update wrapper component that allows for an easy "--self-update" process to be included.
Stephan Hochdörfer
in reply to Skoop (Stefan Koopmanschap) • • •Daniel Siepmann
in reply to Skoop (Stefan Koopmanschap) • •Skoop (Stefan Koopmanschap)
in reply to Daniel Siepmann • • •Daniel Siepmann likes this.
Daniel Siepmann
in reply to Skoop (Stefan Koopmanschap) • •I guess because phpstan already follows the same approach …
I don't think you will get phar from official rector: https://github.com/rectorphp/rector/issues/7824 I'm sorry.