Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

python3Packages.torch: redundancy and fragility fetching source #276585

Closed
zeuner opened this issue Dec 25, 2023 · 1 comment · Fixed by #277789
Closed

python3Packages.torch: redundancy and fragility fetching source #276585

zeuner opened this issue Dec 25, 2023 · 1 comment · Fixed by #277789

Comments

@zeuner
Copy link
Contributor

zeuner commented Dec 25, 2023

Describe the bug

By now, the recursive Git source has to retrieve 71 repository copies, of which there are e.g. 6 copies of googletest and 4 copies of pybind11. This could not only be considered as containing much redundant data, it is also not very robust considering that it suffices to have fetch failures on one of the 71 repository clones to have the whole source derivation fail. On less robust uplinks, this can make it prohibitively unreliable to retrieve a source tree for building. Appropriate behaviour also in presence of transmission errors should be expected, as fetchurl also handles these cases.

Steps To Reproduce

Steps to reproduce the behavior:

  1. Trigger a build from source on an unreliable uplink
  2. See it fail when fetching one of the submodules can't be fetched

Expected behavior

Provide a reasonable number of retries in proportion to the number of files to fetch.

Additional context

Obviously, this issue is not directly caused by torch, but since it surfaces much more severely on this package when compared to other packages, I'm reporting it here.

I would suggest splitting the source fetch derivation into non-recursive derivations for the submodules. This would allow to use the specialized fetchFromGitHub and fetchFromGitLab fetchers, and also to continue when a part of the submodules have already been fetched.

Furthermore, doing so could serve as a starting point to explore whether the submodules actually require different versions of dependencies like googletest (they currently point to different commits), or even to replace some of them by their counterparts from nixpkgs.

Notify maintainers

Will do.

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.0-91-generic, Ubuntu, 22.04.3 LTS (Jammy Jellyfish), nobuild`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.17.0`
 - channels(root): `"nixpkgs"`
 - nixpkgs: `/root/.nix-defexpr/channels/nixpkgs`

Add a 👍 reaction to issues you find important.

@zeuner zeuner added the 0.kind: bug Something is broken label Dec 25, 2023
@zeuner
Copy link
Contributor Author

zeuner commented Dec 25, 2023

@tscholak

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants