| 6 Mar 2024 |
 Pol | * I don't get it! What do you mean ? | 18:27:25 |
 @patka_123:matrix.org | I meant to say don't worry ^^ | 18:27:27 |
| 9 Mar 2024 |
|  mj joined the room. | 03:36:51 |
| 10 Mar 2024 |
| @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).
-
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).
-
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?
| 18:42:50 |
 Jan Tojnar | 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).
-
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).
-
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?
I think a package should only go to phpPackages when it changes behaviour based on PHP environment | 18:58:19 |
| Jan Tojnar | top-level/aliases.nix is only for aliases in top-level, you will need to add the aliases to the phpPackages scope (similarly to how they are done in php extensions) | 18:59:30 |
| @patka_123:matrix.org | In reply to @jtojnar:matrix.org
I think a package should only go to phpPackages when it changes behaviour based on PHP environment So then things like phpstan, codesniffer, php-cs-fixer, phpmd etc all belong outside of phpPackages? Or is that a wrong conclusion? | 19:01:34 |
| Jan Tojnar | it depends on how the tools are implemented | 19:02:31 |
| Jan Tojnar | for example, I know that php-parallel-linter does depend on PHP version | 19:03:02 |
| @patka_123:matrix.org | I'm not sure how to determine that, except for being familiar with the tool itself. Based on what did you determine that about php-parallel-linter for example? I guess something like php-cs-fixer then also changes behaviour based on environment, because it has different rules for different php versions? | 19:06:25 |
| Jan Tojnar | php-parallel-linter just calls php's built-in syntax checker IIRC | 19:07:52 |
| Jan Tojnar | I would expect phpstan and php-cs-fixer implementing everything themselves (IIRC they have target version config option that might default to the current version when not set but should result in the same output regardless the PHP version) | 19:09:53 |
| Jan Tojnar | though searching in memory now, I actually recall that PHPStan did have different results depending on PHP version | 19:11:03 |
| @patka_123:matrix.org | Alright, that does make sense. Thanks for the explanation! I'm going to stay on the safe side, and leave this topic alone for now. I don't feel confident enough yet about making the decision that a package should go to by-name then | 19:13:00 |
| Pol | New PHP PR for improving the PHP builder warning message in case of Composer validation failure: https://github.com/NixOS/nixpkgs/pull/294831 | 21:29:10 |
| 12 Mar 2024 |
| Pol | tgerbet: Are you ok with this? ^^ Eval is red, but that's because of the warning. How to deal with that in nixpkgs? | 09:36:31 |
| 13 Mar 2024 |
| @patka_123:matrix.org | There is now a PHP label, so lets have them added automatically for us :) | 16:35:23 |
| @patka_123:matrix.org | There is now a PHP label, so lets have them added automatically for us :)
https://github.com/NixOS/nixpkgs/pull/295643 | 16:35:33 |
| 14 Mar 2024 |
| Pol | Review required here: https://github.com/NixOS/nixpkgs/pull/295836 | 13:32:28 |
|  NixOS Moderation Botchanged room power levels. | 18:44:59 |
| Pol | Here's a new PR that fixes an issue for the upcoming 8.4 version: https://github.com/NixOS/nixpkgs/pull/295968 | 20:28:59 |
| Pol | It doesn't have an impact on older versions. | 20:29:14 |
| Pol | * It doesn't have an impact on older versions. (I tested) | 20:29:20 |
 tgerbet | In reply to @drupol:matrix.org
tgerbet: Are you ok with this? ^^ Eval is red, but that's because of the warning. How to deal with that in nixpkgs? I do not think lib.warnIf can be used for that. It will always be flagged by the nix-instantiate call done by OfBorg and it is not really an issue within nixpkgs code itself but from upstreams. | 20:44:52 |
| Pol | In reply to @tgerbet:matrix.org
I do not think lib.warnIf can be used for that. It will always be flagged by the nix-instantiate call done by OfBorg and it is not really an issue within nixpkgs code itself but from upstreams. Ok I will rework this. | 20:45:17 |
| Pol | PR updated! https://github.com/NixOS/nixpkgs/pull/294831 | 20:52:29 |
| Pol | Thanks for the review! | 21:30:47 |
| Pol | Thanks :) | 21:58:18 |
| Pol | Et re merci | 22:35:24 |
|  @grahamc:nixos.org joined the room. | 22:37:05 |
