| 7 Feb 2024 |
 @patka_123:matrix.org | In reply to @drupol:matrix.org
Another easy one: https://github.com/NixOS/nixpkgs/issues/262142 Should we do this one at all? Upstream hasn't seen activity for 6 years. Seems like a security risk | 11:55:46 |
 Pol | Then we should close the issue with a valid reason. | 11:58:24 |
| @patka_123:matrix.org | Yeah I'm genuinly wondering because the application itself doesn't do much and the C code is tiny. Might just be that it is stable and working | 12:00:09 |
| Pol | I don't see any security flags in the issue or PR, maybe we should do it still | 12:54:55 |
| @patka_123:matrix.org | I think it would be interesting to find out how to get the ryantm bot to update php packages automatically.
I haven't done much digging. I'll do that tomorrow, but here's the latest log for phpunit.
https://r.ryantm.com/log/phpunit/2024-02-05.log | 18:38:20 |
| Pol | I think Gaël Reyrol did some work in nixpkgs-update, and I think r-ryantm is using it. | 19:55:23 |
| 8 Feb 2024 |
| @patka_123:matrix.org | In reply to @patka_123:matrix.org
Who can make issue labels for nixpkgs? Every language seems to have a "6.topic: java" like tag.
But there's none for php
I think a label "6.topic: php" would still be nice :) I guess you need to be commiter to create a label? | 08:00:18 |
| Pol | Could be done indeed! | 08:07:24 |
|  @marcus_yallow:matrix.org changed their display name from marcus_yallow to pomidor. | 08:37:11 |
| @marcus_yallow:matrix.org changed their display name from pomidor to marcus_yallow. | 08:37:31 |
| @marcus_yallow:matrix.org changed their display name from marcus_yallow to pomidor. | 08:45:47 |
| @marcus_yallow:matrix.org set a profile picture. | 08:45:52 |
| Pol | Elis 🌱, Jan Tojnar how should we deal with this kind of issue? https://discourse.nixos.org/t/php-composer-does-not-find-installed-php-extensions/31164/4
Basically, the xsl extension is not enabled in Composer and it's impossible to install Magento.
Should we:
- Override it locally so that it's enabled for all the versoin of PHP?
- Override it only in Composer derivation ?
- Let the user override it himself?
| 13:35:51 |
| Pol | * Elis 🌱, Jan Tojnar how should we deal with this kind of issue? https://discourse.nixos.org/t/php-composer-does-not-find-installed-php-extensions/31164/4
Basically, the xsl extension is not enabled in Composer and it's impossible to install Magento.
Should we:
- Override it locally so that it's enabled for all the versoin of PHP (system wide)?
- Override it only in Composer derivation ?
- Let the user override it himself?
| 13:36:05 |
| Pol | * Elis 🌱, Jan Tojnar how should we deal with this kind of issue? https://discourse.nixos.org/t/php-composer-does-not-find-installed-php-extensions/31164/4
Basically, the xsl extension is not enabled in Composer and it's impossible to install Magento.
Should we:
- Override it locally so that it's enabled for all the versoin of PHP (system wide)?
- Override it only in Composer derivation (
(php.withExtensions ({ enabled, all }: enabled ++ [ all.xsl ])).buildComposerProject (finalAttrs: {... )?
- Let the user override it himself?
| 13:36:49 |
| Pol | * Elis 🌱, Jan Tojnar how should we deal with this kind of issue? https://discourse.nixos.org/t/php-composer-does-not-find-installed-php-extensions/31164/4
Basically, the xsl extension is not enabled in Composer, making the installation of Magento impossible.
I see 3 possible fix for this:
- Override it locally so that it's enabled for all the versoin of PHP (system wide)?
- Override it only in Composer derivation (
(php.withExtensions ({ enabled, all }: enabled ++ [ all.xsl ])).buildComposerProject (finalAttrs: {... )?
- Let the user override it himself?
What do you think fits best in this case?
| 13:38:32 |
| Pol | * Elis 🌱, Jan Tojnar how should we deal with this kind of issue? https://discourse.nixos.org/t/php-composer-does-not-find-installed-php-extensions/31164/4
Basically, the xsl extension is not enabled in Composer, making the installation of Magento impossible.
I see 3 possible fix for this:
- Override it locally so that it's enabled for all the versoin of PHP (system wide)?
- Override it only in Composer derivation (
(php.withExtensions ({ enabled, all }: enabled ++ [ all.xsl ])).buildComposerProject (finalAttrs: {... )?
- Let the user override it himself? (I propose a solution in the thread)
What do you think fits best in this case?
| 13:44:03 |
 philipp | As a best practice I always have a composer local to the project that get's this project's php and it worked well for me so far. | 13:55:53 |
| Pol | In reply to @philipp:xndr.de
As a best practice I always have a composer local to the project that get's this project's php and it worked well for me so far. So your POV is to have a local flake.nix with a customized composer, just like the solution I proposed in the thread? | 14:15:25 |
| philipp | Yes, pretty much like you said it there. | 14:19:53 |
| Pol | Good thanks for your input. | 14:20:15 |
| @patka_123:matrix.org | But then people have to learn that for some projects they have to create their own composer with the extension enabled. From a user perspective the second option seems best? | 14:54:51 |
| @patka_123:matrix.org | * I also do the same thing. But I'm not sure it's the "best" way as a default.
Because people then have to learn that for some projects they have to create their own composer with the extension enabled. From a user perspective the second option seems best? | 14:56:43 |
| philipp | All you'd really need to tell people is to use yourPHP.packages.composer, right? I don't think that's unreasonable when you are start messing with magento. | 15:04:56 |
| philipp | I might even go so far and call that a good example to understand how to start thinking in nix for beginners. | 15:06:39 |
| Pol | I'm in between 2 waters. At the same time I think Composer should be working out of the box and should not fail and at the same time, I like the idea to let user customize their things. | 15:07:41 |
| @patka_123:matrix.org | I think both are fine. But I still gravitate towards creating a working composer out of the box. Because I have a feeling (that might be wrong) that in other places in nixos it seems like a "policy" to enable things by default to get them working, even if it ends up "bloating" the installation for some people. | 15:20:12 |
| Pol | Quite tricky :) | 15:27:32 |
| Pol | We should check how debian or arch are doing | 15:27:45 |
| philipp | Debian uses whatever is currently php in the current env. | 15:40:38 |
