| 5 Mar 2024 |
 Pol | I've demoed the issue, how it works in Nix... and then he come up with that idea of just updating the composer.lock. | 13:06:42 |
| Pol | At first I was a bit skeptical, because the validity of composer.json vs composer.lock would be broken. | 13:07:17 |
| Pol | But actually, the hash in the composer.lock is just the hash of the composer.json file. | 13:07:34 |
| Pol | So updating the composer.lock file doesn't break the validity check! | 13:07:46 |
 tgerbet | In reply to @drupol:matrix.org
tgerbet: Do you think you could review it at some point? I will take a look at it tonight or tomorrow | 13:35:31 |
| Pol | tgerbet: I think I've fixed it. | 18:37:34 |
| tgerbet | One less jq trick :) | 19:12:55 |
 @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 |
| Pol | patka: Definitely true. | 19:39:25 |
| Pol | This is something I would like to do at some point. | 19:39:34 |
| Pol | In reply to @tgerbet:matrix.org
One less jq trick :) Yep, one things less, it's better and better! | 19:39:56 |
| Pol | 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 |
| Pol | excellent | 19:41:18 |
| Pol | 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 |
| Pol | 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 |
| Pol | No it's fine, help is always welcome | 19:46:29 |
| Pol | tgerbet: backport PR: https://github.com/NixOS/nixpkgs/pull/293574 | 20:17:02 |
| Pol | That PR contains the latest PRs we've been doing for PHP | 20:17:22 |
| Pol | And another one: https://github.com/NixOS/nixpkgs/pull/293582 | 22:10:10 |
| Pol | Validated by Jordi haha :D | 22:12:55 |
| 6 Mar 2024 |
| Pol | tgerbet: Is it ok for you? https://github.com/NixOS/nixpkgs/pull/293574 | 07:21:15 |
| Pol | You reviewed it, but I don't know if the comment is an approval or not | 07:21:31 |
| Pol | 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 |
| Pol | Afk, brb | 11:53:08 |
| Pol | 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 |
