I am pretty -1 on removing sdists. At least for Matplotlib we have a number of users on AIX who rely on the the sdists (I know they exist because when our build breaks they send us patches to un-break it) for their installation. I strongly suspect that numpy also has a fair number of users who are willing and able to compile from source on niche systems and it does seem like a good idea to me to break them. I like Ralf's proposal, but would amend it with "unless someone stands up and puts their name on ensuring the wheels exist for platform <X>" with the understanding that if they have to step away support for that platform stops until someone else is willing to put their name on it. This may be a good candidate for the new SPEC process to handle? Just like supported versions of Python, we should have consistent platform support (and processes for how we decide on / provide that support) across the community (thinking with my Matplotlib and h5py hats here). Tom On Mon, Aug 9, 2021 at 9:51 AM Matti Picus <matti.picus@gmail.com> wrote:
On 16/7/21 9:11 pm, Chris Barker wrote:
Just a note on:
For the record, I am +1 on removing sdists from PyPI until pip changes its default to --only-binary :all: [1]
I agree that the defaults for pip are unfortunate (and indeed the legacy of pip doing, well, a lot, (i.e. building and installing and package managing and dependencies, and ...) with one interface.
However, There's a long tradition of sdists on PyPi -- and PyPi is used, for the most part, as the source of sdists for other systems (conda-forge for example). I did just check, and numpy is an exception -- it's pointing to gitHub:
source: url: https://github.com/numpy/numpy/releases/download/v{{ <https://github.com/numpy/numpy/releases/download/v{{> version }}/numpy-{{ version }}.tar.gz
But others may be counting on sdists on PyPi.
Also, an sdist is not always the same as a gitHub release -- there is some "magic" in building it -- it's not just a copy of the repo. Again, numpy may be building its releases as an sdist (or it just doesn't. matter), but something to keep in mind.
Another thought is to only support platforms that have a committed maintainer -- I think that's how Python itself does it. The more obscure platforms are only supported if someone steps up to support them (I suppose that's technically true for all platforms, but not hard to find someone on the existing core dev team to support the majors). This can be a bit tricky, as the users of a platform may not have the skills to maintain the builds, but it seems fair enough to only support platforms that someone cares enough about to do the work.
-CHB
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov <mailto:Chris.Barker@noaa.gov>
Just an empty response since this ended up in my spam filter, and I am probably not the only one.
Matti
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
-- Thomas Caswell tcaswell@gmail.com