[TASK] Stop version-controlling the development tool PHARs #1175
Conversation
oliverklee
force-pushed
the
task/no-phars
branch
from
f6afd55
to
51c747b
Compare
| <phar name="composer-normalize" version="^2.28.3" installed="2.28.3" location="./.phive/composer-normalize" copy="true"/> | ||
| <phar name="phar-io/phive" version="^0.14.5" installed="0.14.5" location="./.phive/phive" copy="true"/> | ||
| <phar name="php-cs-fixer" version="^3.11.0" installed="3.11.0" location="./.phive/php-cs-fixer" copy="true"/> | ||
| <phar name="phpcs" version="^3.7.1" installed="3.7.1" location="./.phive/phpcs" copy="true"/> | ||
| <phar name="phpmd" version="^2.13.0" installed="2.13.0" location="./.phive/phpmd" copy="true"/> | ||
| <phar name="psalm" version="^4.27.0" installed="4.27.0" location="./.phive/psalm" copy="true"/> |
There was a problem hiding this comment.
This still seems to be saying that the phars are installed. But if they've been taken out of version control, they may not be (and probably won't be on the CI build server). What is the suggested phars.xml content before PHIVE is run to install the packages?
Also, I don't know what copy=[true|false] means. I'm sure I could look it up, but if you know and have a quick explanation you could provide, that would save me time hunting around.
Otherwise looks good. I saw your Twitter poll responses with over 60% in agreement of this approach (from a choice of three). Well done with that. (Social media does have a use, after all.)
I assume when the CI build runs, it will install the latest and greatest that satisfies the version requirement. And we won't have a DEPENDENCIES=lowest option here (it is not necessary, though useful from a testing POV - see #1174 (comment)).
There was a problem hiding this comment.
This ...
Not sure why this is appearing twice.
There was a problem hiding this comment.
This ...
Not sure why this is appearing twice.
Maybe just my end. I've refreshed and it now only appears once.
There was a problem hiding this comment.
The PHIVE configuration file works a bit like a combination of composer.json and composer.lock: The version requirement determines which versions are allowed when phive update is called, while the installed version determines the exact version that gets installed when phive install is called (which is what we're doing in the CI jobs).
When we're using copy=true, the PHAR is installed in the project folder. If we're using `copy=false´, the PHAR is installed on a central directory on the machine and them symlinked to the project directory.
There was a problem hiding this comment.
The PHIVE configuration file works a bit like a combination of
composer.jsonandcomposer.lock: Theversionrequirement determines which versions are allowed whenphive updateis called, while theinstalledversion determines the exact version that gets installed whenphive installis called (which is what we're doing in the CI jobs).
Seems a bit weird to me.
But I have always found the way PHIVE works to be quite odd.
I trust your explanation.
When we're using
copy=true, the PHAR is installed in the project folder. If we're using `copy=false´, the PHAR is installed on a central directory on the machine and them symlinked to the project directory.
Thanks. I did already discover that previously, but had completely forgotton.
oliverklee
force-pushed
the
task/no-phars
branch
from
51c747b
to
20ac699
Compare
Fixes #984