| 5 Mar 2024 |
 @patka_123:matrix.org | There's not really much reason behind when a package is within phpPackages and when it is by-name, is there? (I understand the intention between the seperation, but currently there are a lot of tool within the phpPackages). A thing like phpstan might as well be in by-name, right? | 19:33:22 |
 @drupol:matrix.org | patka: Definitely true. | 19:39:25 |
| @drupol:matrix.org | This is something I would like to do at some point. | 19:39:34 |
| @drupol:matrix.org | In reply to @tgerbet:matrix.org
One less jq trick :) Yep, one things less, it's better and better! | 19:39:56 |
| @drupol:matrix.org | I guess we can safely merge | 19:40:08 |
 tgerbet | Done, I was waiting the confirmation from at least one Darwin builder | 19:41:01 |
| @drupol:matrix.org | excellent | 19:41:18 |
| @drupol:matrix.org | who's taking care of the backport? | 19:41:30 |
| @patka_123:matrix.org | Pol you mean moving to by-name? Then there won't be much phpPackages left, right?
I'd like to try a package since I think it would be interesting to figure out how to move something to by-name. | 19:42:14 |
| @drupol:matrix.org | In reply to @patka_123:matrix.org
Pol you mean moving to by-name? Then there won't be much phpPackages left, right?
I'd like to try a package since I think it would be interesting to figure out how to move something to by-name. yes, you can start with PHPStan or PSalm ? | 19:42:49 |
| @patka_123:matrix.org | Yeah, I think I'll go with phpstan, since I use that at work so then I'll also add myself as maintainer | 19:44:14 |
| @patka_123:matrix.org | Would it be a problem if I add myself as a php maintainer btw? I guess I'm still a newb, but more active than some currently on the list | 19:45:10 |
| @drupol:matrix.org | No it's fine, help is always welcome | 19:46:29 |
| @drupol:matrix.org | tgerbet: backport PR: https://github.com/NixOS/nixpkgs/pull/293574 | 20:17:02 |
| @drupol:matrix.org | That PR contains the latest PRs we've been doing for PHP | 20:17:22 |
| @drupol:matrix.org | And another one: https://github.com/NixOS/nixpkgs/pull/293582 | 22:10:10 |
| @drupol:matrix.org | Validated by Jordi haha :D | 22:12:55 |
| 6 Mar 2024 |
| @drupol:matrix.org | tgerbet: Is it ok for you? https://github.com/NixOS/nixpkgs/pull/293574 | 07:21:15 |
| @drupol:matrix.org | You reviewed it, but I don't know if the comment is an approval or not | 07:21:31 |
| @drupol:matrix.org | Thank you ! | 08:05:24 |
| @patka_123:matrix.org | 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) | 11:49:48 |
| @drupol:matrix.org | Afk, brb | 11:53:08 |
| @drupol:matrix.org | I'm also unsure about the approach to take. Exemple in this PR: https://github.com/NixOS/nixpkgs/pull/293574, tgerbet told me to remove some commits. I'm also learning here. | 12:11:46 |
| @patka_123:matrix.org | Maybe someone else in here can chime in with their experiences. I was planning to ask this in #dev:nixos.org as well, but later this week | 12:17:30 |
| @drupol:matrix.org | I would definitely be interested to know more about it as well. | 12:36:00 |
| tgerbet | 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
| 18:06:51 |
| @drupol:matrix.org | tgerbet: I hope you're OK when I ping you about PRs here | 18:26:03 |
| @drupol:matrix.org | Please, let me know if you think it's not appropriate. | 18:26:16 |
| @drupol:matrix.org | I don't want people to get bored/burntout/leaving because of me! | 18:26:33 |
| @patka_123:matrix.org | In reply to @drupol:matrix.org
I don't want people to get bored/burntout/leaving because of me! But you are Pol, this will not happen! :D | 18:26:51 |
