On Aug 13, 2015 8:47 PM, "Nathaniel Smith" <n...@pobox.com> wrote:
>> On Thu, Aug 13, 2015 at 12:30 PM, Leonardo Rochael Almeida> <leor...@gmail.com> wrote:> >> > On 13 August 2015 at 11:07, Nate Coraor <n...@bx.psu.edu> wrote:> >>> >> On Wed, Aug 12, 2015 at 9:05 PM, Nathaniel Smith <n...@pobox.com> wrote:> >>>> [...]> >>> (2) the special hard-coded tag "centos5". (That's what everyone
> >>> uses in practice, right?)> >>> >>> >> The idea here is that we should attempt to install centos5 wheels if
> >> specific wheels for the platform aren't available?> >> >> > Just my opinion, but although I'm +1 on Nate's efforts, I'm -1 on both
> > standard behavior for installation being the exact platform tag, and an> > automatic fallback to cento5.> >> > IMO, on Linux, the default should always be to opt in to the desired> > platform tags.> >> > We could make it so that the word `default` inside> > `binary-compatibility.cfg` means an exact match on the distro version,
> > that we could simplify the documentation.> >> > But I don't want to upgrade to pip and suddenly find myself installing> > binary wheels compiled by whomever for whatever platform I have no
> > with, even assuming the best of the package builders intentions.> >> > And I certainly don't want centos5 wheels accidentally installed on my> > ubuntu servers unless I very specifically asked for them.> >> > The tiny pain inflicted by telling users to add a one-line text file in
> > very well known location (or two lines, for the added centos5), so that
> > can get the benefit of binary wheels on linux, is very small compared
> > pain of repeatable install scripts suddenly behaving differently and> > installing binary wheels in systems that were prepared to pay the price
> > source installs, including the setting of build environment variables
> > correctly tweaked their build process.>> I think there are two issues here:>> 1) You don't want centos5 wheels "accidentally" installed on an ubuntu> server: Fair enough, you're right; we should probably make the "this> wheel should work on pretty much any linux out there" tag be something> that distributors have to explicitly opt into (similar to how they> have to opt into creating universal wheels), rather than having it be> something you could get by just typing 'pip wheel foo' on the right> (wrong) machine.>> 2) You want it to be the case that if I type 'pip install foo' on a> Linux machine, and pip finds both an sdist and a wheel, where the> wheel is definitely compatible with the current system, then it should> still always prefer the sdist unless configured otherwise: Here I> disagree strongly. This is inconsistent with how things work on every> other platform, it's inconsistent with how pip is being used on Linux> right now with private wheelhouses, and the "tiny pain" of editing a> file in /etc is a huge barrier to new users, many of whom are> uncomfortable editing config files and may not have root access.
So, there would be a capability / osnamestr mapping, or just [...]?
Because my libc headers are different.
>> --> Nathaniel J. Smith -- http://vorpus.org> _______________________________________________> Distutils-SIG maillist - Dist...@python.org> https://mail.python.org/mailman/listinfo/distutils-sig
Distutils-SIG maillist - Dist...@python.org