PHIVE not supported by PHIVE

[JakeQZ]

We need to install a copy of PHIVE because it is not natively available to GitHub Actions (see actions/runner-images#199).

We need to be able to run PHIVE to switch to a different version of, say, PHPUnit, to be able to run tests against all versions of PHP (from 7.1 through 8.0).

It would seem logical to add PHIVE itself to the phive.xml file, but it seems this is not possible, so we must manually download the .phar and dump it in some tools directory. We will later find we have an obsolete version and need to manually update it.

[theseer]

Isn't that a chicken and egg type of scenario? You'd need phive to install phive...?

If you have phive already available, you can simply run phive selfudpate to get its latest version. Nothing manual about that - except calling selfupdate of course.

How would being able to use phive to install itself help?

[JakeQZ]

Maybe we are doing things wrong by storing a copy of the .phar files obtained by PHIVE under version control. But as I already pointed out, PHIVE is not available to GitHub Actions, so we need that.

But now we find we do need PHIVE available to GitHub Actions in order to switch versions depending on which version of PHP is being used. Thus it would make sense to be able to use the same workflow for PHIVE itself. Otherwise, we could just dump a bunch of .phar files in a tools directory, manually update them from time to time, and not use PHIVE at all, which rather defeats the point.

In Linux, the C compiler compiles itself...

How would being able to use phive to install itself help?

I mean to install or update a copy of itself.

[theseer]

I'm still not sure I understand you. Let me try to explain myself by thinking out loud :)

You say, paraphrased from what I understood, that Github Actions do not come with a preinstalled phive thus you have to use phive to install it by itself. That's clearly a chicken and egg problem and can never be resolved. Your reference to the C compliler doesn't change that as the trick there is that you already have a c compiler on the system that you call to compile the next higher level. If that's actually a simpler/older version of the very same c compiler is an irrelevant detail.

You also say, you have all tools in version control. That's certainly not wrong but I don't see how that would support your described use case of switching PHPUnit versions on CI? We do not support installing multiple versions of the same phar in parallel.

So I guess that's where your idea of using phive on CI probably comes from. But that violates the concept of having all tools under version control?

But maybe I don't have to understand this ;)

Your original issue was that you claim phive cannot install itself. That's not correct, we just didn't register an alias for ourselves so you have to use the github namespace and project name:

phive install phar-io/phive

If that doesn't work, that would be a clear bug to be reported against https://github.com/phar-io/phive/issues

[theseer]

I'll close this, as I don't believe there is nothing for us to do.

[JakeQZ]

we just didn't register an alias for ourselves so you have to use the github namespace and project name:

phive install phar-io/phive

OK, that sounds like it should work, but I get

[ERROR]   No RateLimit present in response

[theseer]

What version of phive are you using?

[JakeQZ]

What version of phive are you using?

Aha, sorted. I was using 0.13.2 (installed 'globally'). With 0.13.5 this now works. Thanks :)

[JakeQZ]

FYI, MyIntervals/emogrifier#930 is why I was asking. Hopefully this reference explains where I was coming from. As you can see, I got it sorted (hopefully). Thanks again.