<civodul>so "pip install torch" downloads an 830MB wheel that contains things like libgomp.so and libcudart.so (!)
<civodul>i think we should take a step back and raise awareness of these issues
<civodul>cuz i/we keep preaching to the choir but the vast majority of users probably doesn't understand why we'd bother with Guix packaging when "pip install" works "so well", even for non-Python packages like this one
<wehlutyk[m]>I was following the conversation from afar and thought I can add something to the communication challenge mentioned earlier
<wehlutyk[m]>you're probably aware of this, but the incentive system in academia is also working against people being able to see this problem. A PhD is 3 years, with evaluations every year. Most postdocs are 1 or 2 years, sometimes down to 6 or 9 months.
<wehlutyk[m]>The pressure for stable positions after postdocs is huge and growing. So it's very difficult for people to spend time making sure their code will reproduce 10 years down the line.
<wehlutyk[m]>This is probably even worse in deep learning where the shelf life of a new network architecture is less than 2 years
<civodul>i think pushing scientific reproducibility, and thus reproducible deployment, also means inevitably bringing such issues to the table
<wehlutyk[m]>On the other hand, my experience is that Guix is an easy sell for HPC users outside computer science and physics, as larger teams need to install a lot field-specific software, and coordinate people's environments (at least this is what I'm seeing now in neuroscience -- the only challenge still being that I haven't found the time to get a shared daemon to run as non root)
<dstolfa>civodul: does guix have a way to say "please build all of the packages that depend on this package"? if so, it might be possible to scale up review in a way that a buildbot can just build everything in CI and give automated feedback, at least for some things.
<drakonis>it would be interesting to have a branch that has automatically bumped packages
<drakonis>dstolfa: that is indeed what i want, but applying that to a group with packages, map would probably do the trick?
<dstolfa>drakonis: is there a reason it can't be explicit in the packages themselves? it would be good for it to be explicit, if only for people looking at it later to be able to see that it depends on a particular compiler version
<dstolfa>i understand some people need to change to compiler for one reason or another, but if the reason is "i wanna use a different compiler", then it's probably best to just change the default and build everything locally *shrug*
<dstolfa>of course you can map over it since it's just guile records but i feel like it's not the prettiest code
<drakonis>technically this is the same kind of hackery that happens in nix afaik
<dstolfa>they'd probably need to check that the builds they're doing are reproducible and compose well with the rest of guix... there's no saying what changing a default compiler might do (or building some with 1 and others with another without testing)
<drakonis>i don't think that'd be much of a consideration right now