fix #7606: Include composer files in phar
This change is completely untested! It will hopefully fix issue #7606 by allowing PackageVersions\Versions::getVersion to read version numbers from the composer files when using the CLI.
If successful, then:
-
composer.jsonandcomposer.lockfiles will be included in the phar archive when built, and - when running
php psalm.phar -vfrom the command-line, the correct version number will be reported.
There's a script in the bin directory to build the phar, which could then be tested. I'll try it tomorrow and see if this fixes it.
the CI on PR actually generates a phar. It should be available here: https://output.circle-artifacts.com/output/job/74cf1ac8-3a6e-46bf-b155-b4054b65780d/artifacts/0/build/psalm.phar
Where is the version actually coming from though? I assume if we test the build from this branch it'll correctly say it's the dev version, but we want to know if it'll work for an actual release.
the CI on PR actually generates a phar. It should be available here: https://output.circle-artifacts.com/output/job/74cf1ac8-3a6e-46bf-b155-b4054b65780d/artifacts/0/build/psalm.phar
The phar archive does contain composer.json and composer.lock files. I get
> php psalm.phar -v
Psalm 4.x-dev@2495516e7b0c2cd6b429e51d4f3dcce3cf6d821a
Not sure if that is what would be expected or not.
Right! I wasn't thinking :p
When I try on one of my projects without the phar it reports Psalm 4.24.0@06dd975cb55d36af80f242561738f16c5f58264f which I assume comes from:
...
{
"name": "vimeo/psalm",
"version": "4.24.0",
"source": {
"type": "git",
"url": "https://github.com/vimeo/psalm.git",
"reference": "06dd975cb55d36af80f242561738f16c5f58264f"
},
...
in that project's composer.lock. Are we sure Psalm's composer.lock matters for this? If so, do we have to change/add a version number in composer.json or composer.lock before building the phar?
Apologies if I'm not following or getting confused here. If someone is loading Psalm using a phar archive to check a project (rather than composer), then isn't it the case that there is no guarantee that that project uses composer at all, and even if it does, it would possibly not be referencing Psalm or the version of it that is within the phar archive? Therefore, the version number of psalm in the phar archive needs to be defined within the phar archive itself. It cannot be determined from something outside. If Psalm is attempting to read a version number from a composer.lock file located outside the phar archive itself, then that's a bug?
@mind-bending-forks correct. I'm just trying to figure out where the version number is coming from, and knowing where it comes from without the phar might help know where it comes from for the phar. I figure the version number for the phar probably works similarly to what happens if you run ./psalm on this repository, so maybe I'll try debugging that tomorrow.
I think what might need to happen is that we'll have to add a step to the release process to set the version number for the phar somehow, and I'm not sure if composer.lock or composer.json actually need included in the phar.
The version number comes from various files in vendor/composer directory. If Psalm was installed (during the build, for phar variant) using a recent version of composer, the data comes from vendor/composer/installed.php.
4.x branch is closed now as we prepare for the 5.0 release. Please target the master branch instead.
Closing as this targets 4.x which is closed. Please reopen on master going forward