 | Nix PHP | 80 Members |
| A room for PHP developers running on Nix | 22 Servers |
| Nix PHP | 80 Members |
| A room for PHP developers running on Nix | 22 Servers |
| Sender | Message | Time |
|---|---|---|
| 28 Mar 2023 | ||
 etu | Then we also bump the default PHP used right after the XX.05 release to figure out what breaks before the XX.11 release 🙂 | 08:08:47 |
 philipp | Also PHP 7.4 isn't just deprecated. It's eol. What is deprecated is php 8.0 | 08:13:33 |
| etu | So PHP 8.0 will be dropped May or so just to find breaking points. :) | 08:15:21 |
| etu | * The reason we drop it right after the XX.05 release is that it gives time to figure out everything that breaks of the removal before the XX.11 release 🙂 | 08:15:36 |
 Pol | What's wrong with what I did ? | 09:07:49 |
| philipp | I actually think that it would be better to use php in the function header and then set the version in callPackage is a better way to do it. Also I wouldn't overwrite the php version away from the global default in nixpkgs (php81) unless there is a specific reason to do it. | 09:14:57 |
| philipp | I put my remarks in the nixpkgs pr where they belong... | 09:17:11 |
| Pol | Nice, very good idea. | 09:37:25 |
| Pol | I also replicated that in n98-magerun | 09:37:33 |
| Pol | The commit is also inside that PR, I guess it's not an issue. | 09:37:46 |
| Pol | https://github.com/NixOS/nixpkgs/pull/223365 | 09:37:49 |
 Gaël Reyrol | Pol: there is nothing wrong, etu kind of headed where I wanted to but I wasn't enough explicit! | 09:57:32 |
| Pol | oki | 09:58:28 |
| Pol | philipp: Feel free to let me know if it's better now | 13:29:29 |
| 29 Mar 2023 | ||
| Pol | Hey PHPers, Do you think we can do something similar but for PHP ? | 07:18:42 |
| Pol | * Hey PHPers, Do you think we can do something similar but for PHP ? | 07:21:45 |
| Pol | * Hey PHPers, Do you think we can do something similar but for PHP ? This is the file handling the import of the | 07:23:31 |
| philipp | https://github.com/NixOS/nixpkgs/blob/nixos-22.11/pkgs/tools/networking/rustcat/default.nix This is an example of usage of this, right? What I really don't like about this method is that it completely hides all dependencies from the rest of the system. | 07:32:25 |
 ma27 | AFAIU Pol was specifically talking about the approach where you import the Cargo.lock rather than using a FOD and this method doesn't have this flaw, correct? | 07:35:28 |
| philipp | Oh, that would be cool. | 07:35:51 |
| philipp | Is there an example of it's usage in nixpkgs somewhere? | 07:37:59 |
| ma27 | Regarding the original question: without having taken a close look I think that this should be possible and I'd really like it (especially because I could get rid of at least one occurrence of composer2nix in my employer's deployment I guess). | 07:38:43 |
| ma27 | in other words, congrats you got the job :P | 07:38:50 |
| philipp | Yeah, if it works like that, I'd delighted to have it. | 07:40:00 |
 tgerbet | I do not think it's possible, we do not always have the shasum in the composer lockfile | 07:43:34 |
| ma27 | In reply to @tgerbet:matrix.orgDoesn't each dependency in the lockfile have a source field with a content hash? But I may be missing your point :) | 07:44:41 |
| tgerbet | I remember correctly no, Composer does not set shasum for "Git" packages (even if it uses the GitHub API to download the package...) | 07:52:56 |
| tgerbet | * If I remember correctly no, Composer does not set shasum for "Git" packages (even if it uses the GitHub API to download the package...) | 07:53:02 |
| philipp | Seems so, at least from the lock files I just checked. | 07:53:46 |
| philipp | But builtins.fetchgit also doesn't require a shasum, right? | 07:54:54 |