This is a multi-part message in MIME format.
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
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-signature">
<style type="text/css">* { padding: 0px; margin: 0px; }
body, html { font-family: Arial, San-Serif; font-size: small; color: black; padding-left: 10px; padding-top: 3px; }
a { text-decoration: none; color: #818285; }
h1 { font-size: large; }
table { font-size: 12px; }
p + p { padding-top: 1em; </style>Hi Michael,</div>
<div class="moz-signature"><br>
</div>
<div class="moz-signature">Looks like we keep bumping into each
other ... and not only on PHP packages.</div>
<div class="moz-signature"><br>
</div>
<div class="moz-signature">n 2024/09/11 13:26, Michael Orlitzky
wrote:<br>
</div>
<blockquote type="cite" cite="mid:
daf49b993b2b020a8ddaf7b79bd169e010083812.camel@gentoo.org">
<pre class="moz-quote-pre" wrap="">On Wed, 2024-09-11 at 09:33 +0200, Jaco Kroon wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
<a class="moz-txt-link-freetext" href="
https://github.com/gentoo/gentoo/pull/2905">https://github.com/gentoo/gentoo/pull/2905</a></pre>
</blockquote>
<blockquote type="cite" cite="mid:
daf49b993b2b020a8ddaf7b79bd169e010083812.camel@gentoo.org">
<pre class="moz-quote-pre" wrap="">
(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:
<a class="moz-txt-link-freetext" href="
https://wiki.gentoo.org/wiki/Composer_packaging">https://wiki.gentoo.org/wiki/Composer_packaging</a>
IIRC the "classmap" format is particularly annoying because you have to regenerate it with every release.</pre>
</blockquote>
<p><br>
</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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?</p>
<p>Looking at what one of our clients did is they have a versioned
composer.phar ... which means deps are packaged.</p>
<p><a class="moz-txt-link-freetext" href="
https://getcomposer.org/download/">https://getcomposer.org/download/</a> has these lower down, so IMHO
three options here:<br>
<br>
1. Let users (myself included) just download and use that.<br>
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).<br>
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.</p>
<p>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.<br>
<br>
Your opinion?<br>
</p>
<p>Kind regards,<br>
Jaco</p>
</body>
</html>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)