| 6 Feb 2024 |
 @patka_123:matrix.org | * I thought since phpunit is already packaged I might as well package Pest :D | 20:52:56 |
 Pol | You're free to do it indeed | 20:59:39 |
| Pol | Even if I have my own personal opinion on some frameworks, Nix is not here to judge or anything. If you want to provide it in Nix, got for it. | 21:00:13 |
| Pol | The more package we have, the more likely Nix is going to be adopted by many people. | 21:00:29 |
| @patka_123:matrix.org | I also have pretty strong personal opinions about certain frameworks and even about PHP itself ^^ I'm not a fan of Pest at all. But it is pretty big so it'd be good to have that packaged regardless :) | 21:04:46 |
| Pol | Likewise. | 21:06:40 |
| Pol | send your PR and I'll review it. | 21:06:49 |
| Pol | A fresh PR I just made where you can get some inspiration: https://github.com/NixOS/nixpkgs/pull/286809 | 21:07:08 |
| Pol | Let's see how they are going to react with this: https://github.com/Smile-SA/gdpr-dump/issues/95 | 21:08:16 |
| @patka_123:matrix.org | Oh, I'm already done. Just finishing some things now | 21:14:10 |
| @patka_123:matrix.org | Here it is: https://github.com/NixOS/nixpkgs/pull/286816 | 21:31:42 |
| Pol | https://github.com/NixOS/nixpkgs/actions/runs/7806376986/job/21292605678?pr=286816 | 21:33:16 |
| @patka_123:matrix.org | Yeah I saw that. Fixing it now :) | 21:36:08 |
| Pol | Beside that, all good ! | 21:36:40 |
| @patka_123:matrix.org | Done | 21:43:33 |
| Pol | I'll merge it when tests are green | 21:47:09 |
| Pol | Thanks for it! | 21:47:32 |
| @patka_123:matrix.org | Thanks so far! Have a nice evening | 21:48:17 |
| Pol | You too ! Bye! | 21:50:16 |
| @patka_123:matrix.org | In reply to @drupol:matrix.org
Let's see how they are going to react with this: https://github.com/Smile-SA/gdpr-dump/issues/95 I was thinking for two whole seconds to do this for Pest as well. But I know the answer I'm going to get and don't feel like wasting energy on it | 22:02:57 |
| Pol | In reply to @patka_123:matrix.org
I was thinking for two whole seconds to do this for Pest as well. But I know the answer I'm going to get and don't feel like wasting energy on it Please do it, but I won't! | 22:04:20 |
| Pol | In reply to @patka_123:matrix.org
I was thinking for two whole seconds to do this for Pest as well. But I know the answer I'm going to get and don't feel like wasting energy on it https://github.com/php-parallel-lint/PHP-Parallel-Lint/issues/153 that issue makes we want to reconsider adding composer.lock in nixpkgs | 22:06:49 |
| 7 Feb 2024 |
| @patka_123:matrix.org | That is a good explanation of why a lot of projects don't provide a composer.lock. The FOSS packages we maintain at $work also don't have a lock | 05:08:45 |
| @patka_123:matrix.org | In reply to @drupol:matrix.org
https://github.com/php-parallel-lint/PHP-Parallel-Lint/issues/153 that issue makes we want to reconsider adding composer.lock in nixpkgs I don't understand this. Putting a package under by-name is done for applications, so there you want a lock file. The application is the "end user" and thus decides all versions.
If you have some kind of library that might be a dependency elsewhere then the package should be in something like php83. and you still want a lock file.
We can't magically figure out at runtime which dependencies to build if there is no lockfile.
| 06:05:55 |
| @patka_123:matrix.org | Or am I missing something? | 06:06:15 |
 @etu:failar.nu | In reply to @drupol:matrix.org
Elis 🌱: Have a look at how Rector is packaged... https://github.com/rectorphp/rector Yeah... I mean... it's one way :D | 06:12:03 |
| @patka_123:matrix.org | In reply to @drupol:matrix.org
Elis 🌱: Have a look at how Rector is packaged... https://github.com/rectorphp/rector To me it makes sense. They are just "vendoring" their dependencies so they provide all dependencies for you already.
Unless you override it the dictate the exact dependencies. This seems to me the most reproducible way, isn't it?
| 06:18:45 |
| @patka_123:matrix.org | In reply to @drupol:matrix.org
Elis 🌱: Have a look at how Rector is packaged... https://github.com/rectorphp/rector * | 06:34:29 |
| Pol | In reply to @patka_123:matrix.org
I don't understand this. Putting a package under by-name is done for applications, so there you want a lock file. The application is the "end user" and thus decides all versions.
If you have some kind of library that might be a dependency elsewhere then the package should be in something like php83. and you still want a lock file.
We can't magically figure out at runtime which dependencies to build if there is no lockfile.
Composer.lock should be available if and only if the package you're shipping is meant to be an application. | 08:00:03 |
| Pol | In reply to @patka_123:matrix.org
To me it makes sense. They are just "vendoring" their dependencies so they provide all dependencies for you already. Unless you override it they dictate the exact dependencies. This seems to me the most reproducible way, isn't it? The vendor dir is incomplete. That's the funny part ! | 08:00:39 |
