| 26 Apr 2023 |
 Pol | tgerbet, Jan Tojnar Using composer install --no-autoloader in the FOD, then doing composer dump-autoload works very well. It's even faster to build a PHP derivation. I'm now wondering which route to take.
- The current original route in the PR
- The route with
dump-autoload
- The route with
composition-c4
| 08:20:48 |
 tgerbet | The composition-c4 way to fetch the deps is likely the best way in the sense it is not under the control of Composer so less likely to break | 08:25:18 |
| Pol | I know, I'm sure it's the safest way. | 08:25:56 |
| Pol | I just want to know what we should do here. | 08:26:32 |
| Pol | The problem with composition-c4 is that it is much slower to build a project since it is cloning each project's repo with all the refs. | 08:26:59 |
| Pol | (example, I'm unable to clone phpstan/phpstan here) | 08:27:15 |
| Pol | So, I'm a bit curious on which route to take. | 08:27:29 |
 Jan Tojnar | how are you cloning it? | 08:35:55 |
| Pol | I'm just using c4.composerFetchDeps, nothing else | 08:37:48 |
| Pol | In reply to @tgerbet:matrix.org
The composition-c4 way to fetch the deps is likely the best way in the sense it is not under the control of Composer so less likely to break It's using IFX (impure fixed derivation), and it's not allowed in nixpkgs. | 08:43:31 |
| Pol | In reply to @tgerbet:matrix.org
The composition-c4 way to fetch the deps is likely the best way in the sense it is not under the control of Composer so less likely to break * It's using IFD (impure fixed derivation), and it's not allowed in nixpkgs. | 08:43:40 |
| Pol | * It's using IFD (Import From Derivation), and it's not allowed in nixpkgs. | 08:44:28 |
| tgerbet | Yes but the idea behind composition-c4 is fine: fetching the deps without Composer to build a repository (this is the FOD) then using this repository when doing the install/dumpautoload parts | 08:46:24 |
| tgerbet | Not saying this is easy :p | 08:49:18 |
| Jan Tojnar | yeah, looks like it is another limitation of builtins.fetchGit, it should not be an issue if you replace it with a direct fetching | 08:55:18 |
| Pol | hum.... going to check that. | 08:55:41 |
| Pol | I replaced builtins.fetchGit with fetchgit but that doesn't seem to fix any issue. | 09:32:35 |
| Pol | no it's not. | 09:35:54 |
| Jan Tojnar | fetchgit will require a FOD hash, won’t it? I think you cannot get away from reimplementing the algorithm in something other than Nix | 09:56:42 |
| Pol | Oh man :( | 10:02:11 |
| Pol | So basically, you're telling me that I should write a script that would download all the dependencies with git, and then only we compute the hash on that ? | 10:02:42 |
| Jan Tojnar | yup | 10:03:19 |
| Pol | Damn :( | 10:04:46 |
| Pol | I don't think this is going to work since a "git repo" is not reproducable without a hash. | 10:09:14 |
| Jan Tojnar | you would get the hash for the FOD | 10:15:21 |
| Jan Tojnar | looks like we have this now: https://github.com/NixOS/nixpkgs/blob/9eec23bf5c978829abbb4e90a1d3d418e05a9069/pkgs/build-support/fetchgit/deterministic-git | 10:16:01 |
| tgerbet | For git it can be simplified by removing the .git folder | 10:19:44 |
| tgerbet | It is not really needed for composer | 10:20:00 |
| Pol | In reply to @jtojnar:matrix.org
you would get the hash for the FOD That is ok, but let's say we clone master branch today, and then some commits are pushed, and we clone it again, the hash will be different. I don't see how we could make it reproducable. If there were only one, we could use a revision, but since there are multiple repos to clone... | 10:39:56 |
| Pol | Ok I need some break | 11:22:46 |
