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 " 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 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{{
> > 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
>
>
> 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
