Use newer apereo/phpcas (fixes PHP 8.4 deprecations)

[stweil]

No description provided.

[demiankatz]

Thanks, @stweil! I would much prefer to use a released version than a pinned commit, but this is a good fallback solution if that does not become an option within a reasonable amount of time. We'll discuss this further on next month's Community Call!

[stweil]

See #apereo/phpCAS/pull/444#issuecomment-3155417715 and the question on Slack / vufind-general regarding the future use of phpCAS in VuFind. This PR is only needed if we want to support CAS a little bit longer. And of course a new release of phpCAS would be much better.

[stweil]

Unrelated question: why is the generated file composer.lock part of the version management? I was not sure whether I should include it in my pull request, and it will nearly always cause merge conflicts.

[demiankatz]

Unrelated question: why is the generated file composer.lock part of the version management? I was not sure whether I should include it in my pull request, and it will nearly always cause merge conflicts.

It is important to commit composer.lock, because it ensures that all people running VuFind code get exactly the same dependencies. If we did not commit the lock file and a dependency with an open-ended value in composer.json released a broken version, users who installed dependencies after a certain date would encounter a bug that users who installed before that date would not encounter, and it could be very difficult to troubleshoot.

The general rule (as I see it, anyway) with committing lock-files is that you should commit them in applications (like VuFind) but not commit them in libraries (since you need to leave things open-ended for composition with other libraries).

[demiankatz]

@stweil, when we discussed this on the Community Call, concerns were raised about pointing directly to a GitHub commit in a production release, since (among other issues) it could lead to GitHub rate limits blocking installs. An alternative solution was to deprecate CAS authentication support and skip the problematic tests, which I have implemented for consideration in #4813.

I would obviously prefer to keep CAS support, but if the library is abandoned, I don't think it's worth putting effort into maintaining the feature unless users actively need it -- and I'm not sure if CAS is being used in production anywhere at this point. Do you personally need CAS support, or were you just trying to get rid of the deprecation warnings?

[stweil]

I was just trying to get rid of the nagging deprecation warnings.

For our test instance I started with LDAP, then switched to OpenID Connect.

[stweil]

Personally I also don't like the solution which I implemented in this pull request, but the only better alternatives which would fix the warnings would either require a tagged release with the fix (maybe in a fork) or removing CAS in VuFind.

I would not be concerned about GitHub rate limits. Other GitHub projects like for example OCR-D make heavy use of pull request dependencies, and I never observed a problem with rate limits there.

[demiankatz]

@stweil, with @EreMaijala's help, I think a satisfactory solution has been found at #4813. We've made apereo/phpcas a suggested dependency, so it can be installed if needed but is not there by default. This eliminates the deprecation warnings, which were caused by some auto-executing code introduced by the Composer package. This code is just a waste of resources for the vast majority of users who don't need or want it, so I think it's best to go that route. I am going to close this PR and finish up the other approach.