--trust-gpg-keys option for update

[JakeQZ]

It seems this option is only available for install and not for update.

But install will install the latest version and ignore version constraints set in phive.xml, and there doesn't seem to be a way of specifying version constraints on the command line (at least I can't see anything listed when running phive without parameters to get the built-in help).

[theseer]

It seems this option is only available for install and not for update.

That is correct. Given that to update something it has to have been instaled first, there so far was no point in having that switch here. The only valid edge case I can see that with an update the signing key changes and one would want to automagically allow the updated key.

But install will install the latest version and ignore version constraints set in phive.xml

That should certainly not be the case: If you have an installed version in the phive.xml, that very version is (or should at least) be reinstalled. That's the exact and sole reason to have that information tracked. On update it should update to whatever is latest that still falls into the range defined by the constraint.

and there doesn't seem to be a way of specifying version constraints on the command line (at least I can't see anything listed when running phive without parameters to get the built-in help).

Looks like we're indeed lacking documentation for that. We very much do support that: phive install <package-specifier>@<constraint> (phive install phpunit@^8.0 for instance).

[JakeQZ]

there so far was no point in having that switch here

We're storing the .phars under version control and running the update on a build server (actually just GitHub CI actions), with the .phars copied to a tools directory within the source tree.

So the 'user' running the update won't usually be the same as the one initially installing. Also, as this is an automated process, there is no-one to press Y; we are using echo y | as a workaround but this may have security implications.

(We need to be able to run different versions of PHPUnit depending on the PHP version, because there isn't a version compatible with both PHP 7.2 and PHP 8.)

If you have an installed version in the phive.xml, that very version is (or should at least) be reinstalled.

Starting with the following entry in phive.xml:

  <phar name="phpunit" version="^7.5.20" installed="7.5.20" location="./tools/phpunit.phar" copy="true"/>

I run

phive install phpunit

The phive.xml entry is updated to the following:

  <phar name="phpunit" version="^9.4.3" installed="9.4.3" location="./tools/phpunit" copy="false"/>

The version in `tools' is not updated but a batch file (this is on Windows) is created linking to version 9.4.3 installed for the current user.

Not sure if that's what's supposed to happen. However, if I were to instead run phive update phpunit from the same starting point, no changes are made other than the creation of a batch file linking to the local copy in tools - this is as I would expect.

[theseer]

there so far was no point in having that switch here

We're storing the .phars under version control and running the update on a build server (actually just GitHub CI actions), with the .phars copied to a tools directory within the source tree.

So the 'user' running the update won't usually be the same as the one initially installing.

Interesting use case. Let me think about it. I'm still not convinced, as I don't see this as preferable or even viable process:

• If you run install on the CI instance, it will have the --trust-gpg-keys option. Thus, no problem.

• If you have the tools installed in version control, there is no point in running the update command on CI, as that would violate the idea of having the tools in version control at the first place. You could just as well only commit the phive.xml / .phive/phars.xml file in that case and run install in CI. Again, no Prolblem.

• If you want to manually and explicitly install a specific version, you could use phive install --trust-gpg-keys 0xxxxxxxxx --copy ---temporary phpunit@^8.5.3. (The --temporary ensure the install is not recorded in phive.xml as it's pointless to update it on CI). Again, no problem.

• Even if the full process of installing and updating as well as committing it back to version control would be an - potentially independent - CI job, I cannot see a need for an update.

Also, as this is an automated process, there is no-one to press Y; we are using echo y | as a workaround but this may have security implications.

As your main problem is that your CI run doesn't have the required public key in its key ring because the original install occurred on a different system, you could simply fix that by having the key imported directly using gnupg. phive uses a standard gnupg with a "private" keyring in ~/.phive/gpg.

(We need to be able to run different versions of PHPUnit depending on the PHP version, because there isn't a version compatible with both PHP 7.2 and PHP 8.)

If you have an installed version in the phive.xml, that very version is (or should at least) be reinstalled.

Starting with the following entry in phive.xml:

  <phar name="phpunit" version="^7.5.20" installed="7.5.20" location="./tools/phpunit.phar" copy="true"/>

I run

phive install phpunit

The above command tells phive to install whatever is the latest version of phpunit explicitly ignoring the configured settings in phive.xml. While that works as intended, maybe we should actually change that because I guess it's unexpected behavior and inconsistent with the update command.

For now: If you merely want to re-create the state configured in phive.xml, simply use phive install without any additional parameters.

The version in `tools' is not updated but a batch file (this is on Windows) is created linking to version 9.4.3 installed for the current user.

I see why that is happening and I agree that is probably at least surprising if not wrong: It previously was installed using copy=true and now - because of your call being phive install phpunit - it falls back to it's default of creating a link / batch file. What's indeed seemingly missing is the deletion of the previous install. So I guess that qualifies as a bug ;). One that might vanish when we change the aforementioned behavior of install.

Not sure if that's what's supposed to happen. However, if I were to instead run phive update phpunit from the same starting point, no changes are made other than the creation of a batch file linking to the local copy in tools - this is as I would expect.

Yes. The later indeed seems correct.