| 7 Feb 2024 |
 @patka_123:matrix.org | (I had a look at your other suggestions as well, but those need more research for now as I'm new with these things. But also can't really spend the time on that sort of thing yet) | 11:49:29 |
 @drupol:matrix.org | Right, just do what you can and it's totally fine | 11:50:57 |
| @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 |
| @drupol:matrix.org | 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 |
| @drupol:matrix.org | 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 |
| @drupol:matrix.org | 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 |
| @drupol:matrix.org | 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 |
| @drupol:matrix.org | 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 |
| @drupol:matrix.org | * 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 |
| @drupol:matrix.org | * 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 |
| @drupol:matrix.org | * 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 |
| @drupol:matrix.org | * 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 |
| @drupol:matrix.org | 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 |
| @drupol:matrix.org | 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 |
| @drupol:matrix.org | 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 |
| @drupol:matrix.org | Quite tricky :) | 15:27:32 |
