Nathaniel Smith wrote:
> It's naughty, you shouldn't do it, and the energy you put into making
> pseudo-manylinux1 wheels could probably be better put into making finishing
> up the manylinux2010 work – there's not that much to do.
Can you explain what's missing?
Paul Moore wrote:
> 1. It sounds
On Mon, 17 Sep 2018 at 17:08, Antoine Pitrou wrote:
>
> Paul Moore wrote:
> > I'm not really familiar with manylinux1, but I'd be concerned if we
> > started getting bug reports on pip because we installed a library that
> > claimed to be manylinux1 and was failing because it wasn't. (And yes,
>
On Mon, Sep 17, 2018, 08:25 Antoine Pitrou wrote:
> Hi,
>
> According to recent messages, it seems manylinux2010 won't be ready soon.
> However, the baseline software in manylinux1 is becoming very old. As an
> example, a popular C++ library (Abseil - https://abseil.io/) requires a
> more recent
On Fri, Sep 14, 2018, at 4:26 PM, Paul Moore wrote:
> I don't think it's "hard to predict". I *do* think it's badly documented/not
> standardised.
> ...
> Better would be to have a supported library that exposes the logic pip
> uses (or as I said above, the standard-defined logic) to determine
>
On Tue, 18 Sep 2018 at 19:54, Thomas Kluyver wrote:
>
> On Fri, Sep 14, 2018, at 4:26 PM, Paul Moore wrote:
> > I don't think it's "hard to predict". I *do* think it's badly
> > documented/not standardised.
> > ...
> > Better would be to have a supported library that exposes the logic pip
> >
On Tue, Sep 18, 2018, at 10:02 AM, Antoine Pitrou wrote:
> Nathaniel Smith wrote:
> > It's naughty, you shouldn't do it, and the energy you put into making
> > pseudo-manylinux1 wheels could probably be better put into making finishing
> > up the manylinux2010 work – there's not that much to do.
>
Part of the challenge here from my perspective is that even though I can
envision what the end solution looks like, it's not clear how to actually
get there. How do we designate someone to make decisions about what to
include? How do we protect ourselves against special-case logic being kept
in
> On Sep 18, 2018, at 4:31 PM, Dan Ryan wrote:
>
> As a consequence even though there are other libraries that may provide some
> of this functionality, pip has the reference implementation and that
> contains some significant additional logic. I don't imagine that pip is
> going to simply
> so the people benefiting
> are those who want a supported API for that functionality, and it
> seems only reasonable to expect them to do the job of moving the code,
> rather than expecting the pip developers to do so.
This is where I think we disagree and I feel the rhetoric is a bit harmful
Agreed. Furthermore, if people are of the opinion that pip's
implementation is suitable, copying it out into packaging is likely
not going to be at all controversial. Of course, it's not going to be
any direct advantage to pip if that's done (we get the same
functionality, just in a different
> I would say there's value in having two official manylinux flavors at
once, for example manylinux2010 for maximum compatibility (it's already 8
years old as far as requirements go!) and manylinux2016 for recent systems
compatibility. Later, manylinux2022 gets released as the "recent systems
On Tue, 18 Sep 2018 at 13:45, Olivier Grisel wrote:
>
> > I would say there's value in having two official manylinux flavors at once,
> > for example manylinux2010 for maximum compatibility (it's already 8 years
> > old as far as requirements go!) and manylinux2016 for recent systems
> >
> On Sep 18, 2018, at 8:44 AM, Olivier Grisel wrote:
>
> That's an interesting proposition.
>
> Would pip be able to automatically select the most recent compatible wheel
> when two are available on PyPI?
Yes. Well “recent” isn’t the right way to describe it. Basically when pip is
looking
13 matches
Mail list logo
