| 7 Feb 2024 |
 Pol | Then they should provide the composer.lock file along with the PHAR file. Don't you think? | 11:19:49 |
| Pol | I any case, moving the responsibility of creating the composer.lock file to the users consuming the application is a bad idea in general. They should provide it in a way. | 11:20:49 |
 @patka_123:matrix.org | They can provide it next to the PHAR, but can still decide to not put one in the repo, so end users can create one themselves | 11:21:50 |
| Pol | Yes, that's the middle-ground compromise that I wrote in my message. | 11:23:04 |
| @patka_123:matrix.org | In reply to @drupol:matrix.org
Yes, that's the middle-ground compromise that I wrote in my message. Ah sorry, somehow missed that. | 11:23:42 |
| Pol | 
Download image.png | 11:24:32 |
| @patka_123:matrix.org | That'd be great! | 11:28:34 |
| Pol | OK we finally agree :D | 11:29:23 |
| Pol | In reply to @patka_123:matrix.org
The phar just means that they also distribute an end user application.
If I have a work project and decide to use their tool and use composer for that I'd want to choose my own versions (or at least their their lock is accommodating enough).
So from their POV you can still make a valid case that a lock is not needed. And only useful if you create an end user application (which we do for nixpkgs so we can generate it ourselves)
Just FYI, the most used testing framework in the PHP ecosystem, PHPUnit... did it without any trouble... so I don't see why it wouldn't be possible somewhere else. | 11:37:41 |
| @patka_123:matrix.org | I'm not saying what should be done. Just that if they decide not to provide a lock, that their reason is also valid :) | 11:47:31 |
| @patka_123:matrix.org | Talking about phpunit. Would it be an idea to package paratest? We use that extensively and I see that it is not packaged yet | 11:48:08 |
| Pol | Yeah sure, good idea | 11:48:17 |
| @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 |
| Pol | 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 |
| 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 |
