phive.xml settings are ignored if phar name gets passed

[ThomasNegeli]

Why are version, installed and location attributes ignored from phive.xml?

If I have the following line in the phive.xml: <phar name="xyz-tool" version="^3.0.7" installed="3.0.7" location="./src/bin/xyz-tool" copy="false"/> And a version 3.0.8 of xyz-tool is available, it gets downloaded. Also the location path is ignored, except I specify the --target parameter on phive install.

How can I ensure that I always get the version 3.0.7 of xyz-tool when using phive install xyz-tool

[theseer]

Nice catch for what probably qualifies as unexpected behavior but it works as designed.

When calling phive install xyz-tool indeed the pre-existing entry for xyz-tool is ignored and the latest available version is going to be installed in the standard location (./tools).

To install phars as they are configured in the phive.xml, you need to simply call phive install without any additional arguments.

I guess it would make sense to honor the pre-existing settings as well in case phive's called with tools names.

[jaapio]

@theseer is this issue open for pr's? I was expecting the same behavior. That install would respect the config. And update should be the only command change the config when tools do have an entry.

[theseer]

Well, technically phive install does. Only phive install toolname doesn't. While that might be unexpected behavior as mentioned before, I still don't see a use case for this? Why would you have a phive.xml with a given set of tools and yet try to only install one manually based on a previously set configuration?

That's why I didn't treat this as a high priority issue. Feel free to supply a PR for it :)

[jaapio]

To reduce the number of requests during CI is my use case. For example I'm installing phpunit phpstan and psalm in the same project, but I just want to execute phpstan in a single step. There is no need to install all tools. By now I do get errors because phive cannot check the system requirements and installs phpunit 9 in a php 7.2 environment.

Caching the phive home dir could also be a solution but that doesn't work because of gpg issues on windows. So I do agree this is more or less a workaround for other issues. But it was for me quite an surprise that install doesn't do the same thing as install phpunit

[theseer]

Thank you for supplying this. Don't get me wrong, I'm not opposed to implementing this behavior. I just still don't see the use case. Or maybe: I don't believe the described use case(s) require this behavior.

To reduce the number of requests during CI is my use case. For example I'm installing phpunit phpstan and psalm in the same project, but I just want to execute phpstan in a single step. There is no need to install all tools.

While I understand you might not need all tools at a given run, installing is merely a symlink. At least by default.

By now I do get errors because phive cannot check the system requirements and installs phpunit 9 in a php 7.2 environment.

It may seem that way but it's technically not correct. Phive very much does a check on the system compatibility. But PHPUnit doesn't come with the required manifest to do that. If @sebastianbergmann would add a proper manifest.xml to the phar of PHPUnit as he does and requires for plugins, phive would warn that the environment in use would not be able to run the phar in your example case.

It of course doesn't have the metadata to find a potentially matching version, so you'd have to tell phive which version you want (e.g. phive install phpunit@^8.3 or something). We're considering to add conditional installs to the phive xml (see https://github.com/phar-io/phive/issues/219#issuecomment-659610554), but that's just an idea for now...

So for the time being what you described is indeed what is happening - but only if you use phive the way you described it and because PHPUnit does not come with a manifest.xml.

Why not say phive install phpunit@^8.0 or phive install phpunit@^9.3 or whatever you want in a certain step? I don't see how having phive honor the definition in the phive.xml would help here if you have multiple environments with differing version constraints?

Caching the phive home dir could also be a solution but that doesn't work because of gpg issues on windows.

Sorry, I don't understand this. How is caching related to GPG handling? And what issues on windows? Once downloaded and verified, phive is no longer performing GPG checks on a file. That would be rather pointless ;-)

So what are you trying to tell me here?

So I do agree this is more or less a workaround for other issues. But it was for me quite an surprise that install doesn't do the same thing as install phpunit

Granted, it probably is surprising and should also probably be changed. If you feel like, PR welcome ;)

[mvriel]

What may help as context here is that with Github Actions; each action could run phive again. With phpDocumentor, we run an exhaustive matrix of unit tests that require phive to download its dependencies again and again (see https://github.com/phpDocumentor/phpDocumentor/actions/runs/2634218898) and this causes the "No rate limit in response" issue (running version Phive 0.15.1):

We use the location attribute to install a PHPUnit extension into a subfolder because PHPUnit wants a folder for its extension and will fail to install any extension if we include the whole tools folder.

So what we do to reduce the chance of the "No rate limit in response", is to limit the number of packages to install. But because the config file is ignored, our test suite fails because the PHPUnit extension is installed in the wrong directory