Pol I was wondering a bit about the backport PR's. I think it's generally not done often to create backport for package updates, unless it's a security update or a situation where you can be 100% sure the update doesn't contain any backwards breaking changes. More info here

I think it's virtually impossible (without auditing all the code) to guarentee that something doesn't contain a backward breaking change for for example phpunit or phpstan. Something somewhere only needs a simple typo fix (just a silly example) in an API and there is always someone somewhere that relies on it being with the typo.

And relying on the blue eyes of upstream to not mess up semver is also not a good idea. (packages have semver violations constantly, and we don't have something like "automated" semver checks like in Rust where it helps a bit in that regard)

I tend to limit myself to stuff with security issues and/or annoying bugs when backporting mainly because it is extra work 😅. In this case I merged the PR because:

• the PR was already done
• yes Psalm / PHPStan upgrades can always be considered breaking because they can spot new issues but they also tend to fix quite a bunch of issues. It's not a clear cut. Also in this specific case the Psalm upgrade did not imply any configuration changes.
• Outside of composer itself it is all leaf packages so even if something has a change we missed the impact remains limited
• For composer the changes listed in the "common upgrade issues" of the 2.7.0 release are mainly related to the change made to fix CVE-2024-24821 (please do not run composer as root 😅) and bumping to it allow us to get the recent fixes/improvements made for buildComposerProject

In reply to @drupol:matrix.org
I don't want people to get bored/burntout/leaving because of me!

Jan Tojnar I have two questions you might be able to answer (other people too of course, if they know an answer).

1. What would the best solution be for all the programs under phpPackages that are not really libraries, but standalone apps? I guess they would be more at home in by-name than within phpPackages. But then where do we draw the line because almost everything currently under phpPackages fits this discription. (for example things like phpstan or psalm etc etc).

2. If something goes from phpPackages to by-name is an alias in top-level/aliases.nlx the best place, or is there another mechanism to not break anything for existing users, but still being able to house it in by-name?

In reply to @patka_123:matrix.org

Jan Tojnar I have two questions you might be able to answer (other people too of course, if they know an answer).

1. What would the best solution be for all the programs under phpPackages that are not really libraries, but standalone apps? I guess they would be more at home in by-name than within phpPackages. But then where do we draw the line because almost everything currently under phpPackages fits this discription. (for example things like phpstan or psalm etc etc).

2. If something goes from phpPackages to by-name is an alias in top-level/aliases.nlx the best place, or is there another mechanism to not break anything for existing users, but still being able to house it in by-name?

In reply to @jtojnar:matrix.org
I think a package should only go to phpPackages when it changes behaviour based on PHP environment

There is now a PHP label, so lets have them added automatically for us :)

https://github.com/NixOS/nixpkgs/pull/295643