Certain packages are memory intensive. It would be great if Pkj asked the user to confirm downloading it with a linux-style-message, "
This isn't generally known until after the package is installed. Infrastructure would be needed recording the sizes of all packages and artifacts and making that information available to the user somehow. The Pkg protocol could potentially be used to get this info. Out of curiosity, do any other package manager have this feature?
pacman does this:
Total Download Size: 715.97 MiB
Total Installed Size: 2789.16 MiB
Net Upgrade Size: 11.83 MiB
:: Proceed with installation? [Y/n]
This seems like a lot of infrastructure needed for not that much gain. The majority of packages are quite small. Also, I think a "Do you really want to add this" query for every operation is kinda stupid, of course I want to do it, that's why I asked you to do it. For example, regarding the confirmation that distro package managers do, I don't think I have ever clicked no.
I do have to say that it鈥檚 been a long while since I cared about how much disk something like this used. Sure, it was worrying like 15 years ago but SSDs are, what, a couple terabytes these days? If you install every single Julia package it鈥檚 less than 50GB.
How would one do this given that during the build stage packages can download or create as much data as they want? I don't think that "installation size" is well defined value for julia packages.
You can't give a good answer for packages with deps/build.jl. You can, however, do it for packages that use artifacts since that's completely declarative and we know how big each package and artifact is and which artifacts would get installed on the current system.
A package was not completely added ( weights of the pretrained network, which was close to 150 MB, was not fully downloaded), which I realized looking at the size of few files in deps folder. Although I think a checksum will be implemented there, it seemed like info about memory a nice tool to have.
I agree with most of you that memory isn't a big concern for most part, but I think if we want to explore Julia on embedded systems ( maybe even for embedded ML) it might be crucial for the concerned packages.
Having that said, as it is mentioned that it would require a huge infra to change it, am I expected to close this issue?
It's not that huge a change, but someone needs to build the tooling and infrastructure to compute this and keep that info up-to-date. You can leave it open for a while as a potential enhancement request, although it may not get done unless someone decides they really want it.