For a timely example of how PyPI size limits can be very real, JupyterLab's is hitting this right now:
https://github.com/jupyterlab/jupyterlab/issues/16859 ERROR HTTPError: 400 Bad Request from https://upload.pypi.org/legacy/ Project size too large. Limit for project 'jupyterlab' total size is 10 GB. See https://pypi.org/help/#project-size-limit For them, they are hitting a total size limit of 10 GB. On Wed, Oct 9, 2024 at 6:24 AM Dima Pasechnik <dimp...@gmail.com> wrote: > specifically, this is PEP 759 – External Wheel Hosting ( > https://peps.python.org/pep-0759) > and there > https://peps.python.org/pep-0759/#addressing-pypi-limits > > On Wednesday, October 9, 2024 at 1:12:56 AM UTC+1 Dima Pasechnik wrote: > >> I read on Python Discource a proposal to allow externally hosted >> wheels on PyPI. With PyPI only hosting metadata and >> checksums. I imagine this will lift the size constraints, if accepted. >> >> Dima >> >> On Tuesday, October 8, 2024 at 11:59:12 PM UTC+1 Nils Bruin wrote: >> >>> On Tuesday 8 October 2024 at 15:40:07 UTC-7 oscar.j....@gmail.com wrote: >>> >>> > As you're pointing out, sage still fits within 10GB in source, so it >>> looks like sagemath could just be one pypi package. >>> >>> I think that you have misunderstood the limits that Marc was referring >>> to. The 100MB file limits means that a single project installer file >>> should be less than 100MB. The 10GB project limit means that all >>> installer files for each Python version and each OS for all versions >>> of a project should not add up to more than 10GB. A single Sage >>> installer file for one OS, Sage version and CPython version comes >>> close to the total file size limit allowed for any project by default >>> in PyPI. >>> >>> >>> Thanks for the clarification. So Pypi is wholly unsuitable for >>> distributing a monolithic sagelib. If we want sagelib distributed through >>> pypi then it *has* to be chopped up in order to make it fit. Distributing >>> sagelib through pypi sounds like a pretty good idea, given that pypi is the >>> de facto standard for distributing python software. So it sounds like >>> considerations for reuse in other projects might not even be so relevant >>> for motivating modularization: we already need it to make sage fit onto >>> pypi. But that might also change the consideration for how sagemath needs >>> to be chopped up. For fitting onto pypi, it's sufficient it gets chopped up >>> in roughly equal-sized parts that can be built separately, in some >>> specified order. >>> >> -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/79e2d59c-162d-4162-acb7-7ee7ae958324n%40googlegroups.com > <https://groups.google.com/d/msgid/sage-devel/79e2d59c-162d-4162-acb7-7ee7ae958324n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- William (http://wstein.org) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CACLE5GAVJs_b6L0KoZt_YJ%3DWqGzP%3DXQeDc%2BhiL2xw7dSj9Lt2Q%40mail.gmail.com.
