Hi Michael,
Looks like we keep bumping into each other ... and not only on PHP packages.
n 2024/09/11 13:26, Michael Orlitzky wrote:
On Wed, 2024-09-11 at 09:33 +0200, Jaco Kroon wrote:
Hi,
I missed this announcement, looking specifically for composer again.
If I make the effort of bumping to newest version, is this something
that would be re-added to the tree?
I'd re-commit if you're interested in keeping up with it. It brings a
lot of dependencies with it though. It was initially added in
https://github.com/gentoo/gentoo/pull/2905
(where you can see the deps) and I'll bet the list is even longer now.
Updating them is more annoying than usual because they all want
autoload.php files that aren't in the source tarball:
https://wiki.gentoo.org/wiki/Composer_packaging
IIRC the "classmap" format is particularly annoying because you have to
regenerate it with every release.
Right. What I take away from this is that PHP trying to incorporate
things that annoy me about other languages is a pain in the backside.
All I really need (and I think this is in line with something you
mentioned in one of our other discussions) is that PHP source files are
typically no longer packaged, because everyone uses composer now to just
pull in dependencies from just about anywhere, and often poorly vetted,
outdated versions.
What I really just need is a way to for a specific PHP deployed app be
able to run composer to pull in those dependencies into a normal user
account so that I can properly isolate the specific PHP app.
I think it's useful to have the composer command available on Gentoo,
but I do agree with the principle of letting each deployment manage it's
own rather.
Ie, my *opinion* is that Gentoo should package the interpreters and any
pecl-* stuff which is compiled. And let the apps handle their own sources.
composer I reckon is a bit of a tricky one here because it looks like it
itself is a source-based thing, and pulls in a bunch of it's own deps then?
Looking at what one of our clients did is they have a versioned
composer.phar ... which means deps are packaged.
https://getcomposer.org/download/ has these lower down, so IMHO three
options here:
1. Let users (myself included) just download and use that.
2. We package the phar file rather than the individual deps. Yes, this
is cheating. Like using embedded libs, however, I've seen and observed
that in some cases this makes more sense than splitting them up (eg
clippy and frr).
3. We go about figuring everything out again and bumping all those
individual packages and keeping them all up to date individually. I
don't think this is worth our time and effort.
I honestly think in this case 2 may well be acceptable. Otherwise 1, but
I think 3 is not worth the effort based on your feedback and further
reading from when I originally posed the question to now.
Your opinion?
Kind regards,
Jaco
