Move ensurepip blobs to external place
Currently the repository contains bundled pip and setuptools (2 MB total) which are updated with every release of pip and setuptools. This increases the size of the repository by around 2 MB several times per year. There were total 37 updates of Lib/ensurepip/_bundled, therefore the repository contains up to 70 MB of unused blobs. The size of the repository is 350 MB. Currently blobs takes up to 20% of the size of the repository, but this percent will likely grow in future, because they where added only 4 years ago. Wouldn't be better to put them into a separate repository like Tcl/Tk and other external binaries for Windows, and download only the recent version?
On 24 March 2018 at 18:50, Serhiy Storchaka
Currently the repository contains bundled pip and setuptools (2 MB total) which are updated with every release of pip and setuptools. This increases the size of the repository by around 2 MB several times per year. There were total 37 updates of Lib/ensurepip/_bundled, therefore the repository contains up to 70 MB of unused blobs. The size of the repository is 350 MB. Currently blobs takes up to 20% of the size of the repository, but this percent will likely grow in future, because they where added only 4 years ago.
Wouldn't be better to put them into a separate repository like Tcl/Tk and other external binaries for Windows, and download only the recent version?
Specifically, I believe that would entail adding them to https://github.com/python/cpython-bin-deps, and then updating the make file to do a shallow clone of the relevant branch and copy the binaries to a point where ensurepip expects to find them? I'm fine with the general idea of moving these out to the bin-deps repo, as long as cloning the main CPython repo and running "./configure && make && ./python -m test test_ensurepip" still works. We'd also want to add docs to the developer guide on how to update them (those docs are missing at the moment, since the update process is just dropping the new wheel files directly into the right place) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 24 March 2018 at 10:50, Nick Coghlan
On 24 March 2018 at 18:50, Serhiy Storchaka
wrote: Currently the repository contains bundled pip and setuptools (2 MB total) which are updated with every release of pip and setuptools. This increases the size of the repository by around 2 MB several times per year. There were total 37 updates of Lib/ensurepip/_bundled, therefore the repository contains up to 70 MB of unused blobs. The size of the repository is 350 MB. Currently blobs takes up to 20% of the size of the repository, but this percent will likely grow in future, because they where added only 4 years ago.
Wouldn't be better to put them into a separate repository like Tcl/Tk and other external binaries for Windows, and download only the recent version?
Specifically, I believe that would entail adding them to https://github.com/python/cpython-bin-deps, and then updating the make file to do a shallow clone of the relevant branch and copy the binaries to a point where ensurepip expects to find them?
I'm fine with the general idea of moving these out to the bin-deps repo, as long as cloning the main CPython repo and running "./configure && make && ./python -m test test_ensurepip" still works. We'd also want to add docs to the developer guide on how to update them (those docs are missing at the moment, since the update process is just dropping the new wheel files directly into the right place)
I don't have a problem with moving the pip/setuptools wheels - as long as (as a pip dev doing a release) I know where to put the files, it makes little difference to me. But as Nick says, if the files aren't in the main CPython repository, the build process (both the Unix and the Windows processes) will need updating to ensure that the files are taken from where they do reside and put in the right places. I'd assume that a change like that is big enough that it would be targeted at 3.8, BTW (and so won't affect what I need to do for 3.7). Paul
Or we could just pull the right version directly from PyPI? (Note that updating the version should be an explicit step, as it is today, but the file should be identical to what’s on PyPI, right? And a urlretrieve is easier than pulling from a git repo.)
Top-posted from my Windows phone
From: Paul Moore
Sent: Saturday, March 24, 2018 4:17
To: Nick Coghlan
Cc: Serhiy Storchaka; python-dev
Subject: Re: [Python-Dev] Move ensurepip blobs to external place
On 24 March 2018 at 10:50, Nick Coghlan
On 24 March 2018 at 18:50, Serhiy Storchaka
wrote: Currently the repository contains bundled pip and setuptools (2 MB total) which are updated with every release of pip and setuptools. This increases the size of the repository by around 2 MB several times per year. There were total 37 updates of Lib/ensurepip/_bundled, therefore the repository contains up to 70 MB of unused blobs. The size of the repository is 350 MB. Currently blobs takes up to 20% of the size of the repository, but this percent will likely grow in future, because they where added only 4 years ago.
Wouldn't be better to put them into a separate repository like Tcl/Tk and other external binaries for Windows, and download only the recent version?
Specifically, I believe that would entail adding them to https://github.com/python/cpython-bin-deps, and then updating the make file to do a shallow clone of the relevant branch and copy the binaries to a point where ensurepip expects to find them?
I'm fine with the general idea of moving these out to the bin-deps repo, as long as cloning the main CPython repo and running "./configure && make && ./python -m test test_ensurepip" still works. We'd also want to add docs to the developer guide on how to update them (those docs are missing at the moment, since the update process is just dropping the new wheel files directly into the right place)
I don't have a problem with moving the pip/setuptools wheels - as long as (as a pip dev doing a release) I know where to put the files, it makes little difference to me. But as Nick says, if the files aren't in the main CPython repository, the build process (both the Unix and the Windows processes) will need updating to ensure that the files are taken from where they do reside and put in the right places. I'd assume that a change like that is big enough that it would be targeted at 3.8, BTW (and so won't affect what I need to do for 3.7). Paul _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40python.org
From my POV I don’t care where they live, just document how to update them going forward. Sent from my iPhone
On Mar 24, 2018, at 4:50 AM, Serhiy Storchaka
wrote: Wouldn't be better to put them into a separate repository like Tcl/Tk and other external binaries for Windows, and download only the recent version?
AFAIU, the objectives (with no particular ranking) are: - minimize git clone time and bandwidth - include latest pip with every python install - run the full test suite with CI for every PR (buildbot) - the full test suite requires pip - run the test suite locally when developing a PR - minimize PyPI bandwidth What are the proposed solutions? ... https://help.github.com/articles/about-storage-and-bandwidth-usage/
All personal and organization accounts using Git LFS receive 1 GB of free storage and 1 GB a month of free bandwidth. If the bandwidth and storage quotas are not enough, you can choose to purchase an additional quota for Git LFS.
Git LFS is available for every repository on GitHub, whether or not your account or organization has a paid plan.
On Thursday, March 29, 2018, Donald Stufft
From my POV I don’t care where they live, just document how to update them going forward.
Sent from my iPhone
On Mar 24, 2018, at 4:50 AM, Serhiy Storchaka
wrote: Wouldn't be better to put them into a separate repository like Tcl/Tk and other external binaries for Windows, and download only the recent version?
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ wes.turner%40gmail.com
participants (6)
-
Donald Stufft
-
Nick Coghlan
-
Paul Moore
-
Serhiy Storchaka
-
Steve Dower
-
Wes Turner