phive
phive copied to clipboard
`--trust-gpg-keys` option for `update`
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).
It seems this option is only available for
install
and not forupdate
.
That is correct. Given that to update
something it has to have been instal
ed 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 inphive.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).
there so far was no point in having that switch here
We're storing the .phar
s under version control and running the update on a build server (actually just GitHub CI actions), with the .phar
s 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.
there so far was no point in having that switch here
We're storing the
.phar
s under version control and running the update on a build server (actually just GitHub CI actions), with the.phar
s copied to atools
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 thephive.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 inphive.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 intools
- this is as I would expect.
Yes. The later indeed seems correct.