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.pi...@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.bar...@noaa.gov <mailto:chris.bar...@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 tcasw...@gmail.com
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
