bug#27284: Memory leak in 'guix pull' or 'make' in guix source

[Ricardo Wurmus]

Hi Ludo,

> In the meantime, our best workaround to reduce memory consumption is… to
> split large files into smaller ones.  Per M-x guix-locations, the
> candidates are:
>
>   gnu/packages/python.scm                                   986
>   gnu/packages/perl.scm                                     401
>   gnu/packages/haskell.scm                                  348

[…]

> I think we could focus on the first two or three files.  FTR, compiling
> bioinformatics.scm peaks at ~500 MiB resident on x86_64.
>
> Ricardo, WDYT?

I was hoping we could avoid this, but whatever: let’s do this :)

> If we do this, do we split arbitrarily?  Like the second half of
> python.scm goes to python-cont.scm (provided there are no cross
> top-level references)?  Or do you have a better idea?

Ultimately, I’d like to move packages to locations where they could
permanently live, but that would probably take longer.

Would it make sense to move all the python2-* packages to a new module?
This would make the split rather simple and users wouldn’t have to
remember which of their packages ended up in which half of the modules.
It also means that we probably won’t have to mess with the copyright
headers.

For perl.scm I have no good ideas.  Let’s split it up at an arbitrary
point.

For haskell.scm I’d begin by moving the following packages away:

- check.scm: ghc-tasty*, ghc-quickcheck*, ghc-test*, ghc-hunit*, hspec*,
  ghc-hspec*, …

- web.scm: ghc-tagsoup, ghc-cookie, ghc-http*, ghc-wai*, ghc-json,
  ghc-warp*, ghc-multipart, ghc-aeson*

- crypto.scm: ghc-tf-random, ghc-digest, ghc-cryptonite, ghc-x509*,
  ghc-asn1*, ghc-pem, ghc-cryptohash*, ghc-entropy, ghc-crypto-api*,
  ghc-puremd5

- tls.scm: ghc-tls

Maybe that’s enough already.

Does that seem like a good idea?  I could prepare patches for splitting
up haskell.scm.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net