[Distutils] Re: Environment markers for GPU/CUDA availibility

On 2018-09-04 11:40:17 -0500 (-0500), Dustin Ingram wrote: > On Tue, Sep 4, 2018 at 11:33 AM Jeremy Stanley wrote: > > > > Yes. If you haven't tried running a mirror of PyPI lately you're > > likely not to have noticed, but the various nightly builds for > > tensorflow seem to be the majority of

[Distutils] Re: Environment markers for GPU/CUDA availibility

On Tue, Sep 4, 2018, 07:42 Nick Coghlan wrote: > On Tue, 4 Sep 2018 at 20:30, Nathaniel Smith wrote: > > > > On Mon, Sep 3, 2018 at 4:51 PM, Nick Coghlan wrote: > > > On Mon., 3 Sep. 2018, 5:48 am Ronald Oussoren, > > > > wrote: > > >> > > >> > > >> What’s the problem with including GPU and

[Distutils] Re: Environment markers for GPU/CUDA availibility

On Tue, Sep 4, 2018 at 11:33 AM Jeremy Stanley wrote: > > Yes. If you haven't tried running a mirror of PyPI lately you're > likely not to have noticed, but the various nightly builds for > tensorflow seem to be the majority of the data on PyPI now. I'm sure > it's a very neat and useful tool,

[Distutils] Re: Environment markers for GPU/CUDA availibility

On 2018-09-05 00:42:04 +1000 (+1000), Nick Coghlan wrote: [...] > I didn't actually realise the GPU tensorflow package was over 200 MB, > though - that's large enough to be noticeably slow to extract and > install even from a local zipfile, let alone if you're needing to > download it first. [...]

[Distutils] Re: Environment markers for GPU/CUDA availibility

On Tue, 4 Sep 2018 at 20:50, Paul Moore wrote: > On Tue, 4 Sep 2018 at 11:28, Nathaniel Smith wrote: > > But... do we actually know enough to define a "has_gpu" marker? It > > isn't literally "this system has a gpu", right, it's something more > > like "this system has an NVIDIA-brand GPU of a

[Distutils] Re: Environment markers for GPU/CUDA availibility

On Tue, 4 Sep 2018 at 20:30, Nathaniel Smith wrote: > > On Mon, Sep 3, 2018 at 4:51 PM, Nick Coghlan wrote: > > On Mon., 3 Sep. 2018, 5:48 am Ronald Oussoren, > > wrote: > >> > >> > >> What’s the problem with including GPU and non-GPU variants of code in a > >> binary wheel other than the size

[Distutils] (no subject)

null -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at

[Distutils] Re: Environment markers for GPU/CUDA availibility

On Tue, 4 Sep 2018 at 11:28, Nathaniel Smith wrote: > > On Tue, Sep 4, 2018 at 3:10 AM, Paul Moore wrote: > > There's very much an 80-20 question here, we need to avoid letting the > > needs of the 20% of projects with unusual needs, complicate usage for > > the 80%. On the other hand, of

[Distutils] Re: Environment markers for GPU/CUDA availibility

On Mon, Sep 3, 2018 at 4:51 PM, Nick Coghlan wrote: > On Mon., 3 Sep. 2018, 5:48 am Ronald Oussoren, > wrote: >> >> >> What’s the problem with including GPU and non-GPU variants of code in a >> binary wheel other than the size of the wheel? I tend to prefer binaries >> that work “everywhere",

[Distutils] Re: Environment markers for GPU/CUDA availibility

On Tue, Sep 4, 2018 at 3:10 AM, Paul Moore wrote: > There's very much an 80-20 question here, we need to avoid letting the > needs of the 20% of projects with unusual needs, complicate usage for > the 80%. On the other hand, of course, leaving the specialist cases > with no viable solution also

[Distutils] Re: Environment markers for GPU/CUDA availibility

On Tue, 4 Sep 2018 at 08:07, Ronald Oussoren via Distutils-SIG wrote: > On 4 Sep 2018, at 01:51, Nick Coghlan wrote: > On Mon., 3 Sep. 2018, 5:48 am Ronald Oussoren, wrote: >> >> What’s the problem with including GPU and non-GPU variants of code in a >> binary wheel other than the size of the

[Distutils] Re: manylinux1 guidelines for zlib?

Since zlib is a dependency of python, the assumption has to be that it is already present. I think you can look at the python docs for which versions of zlib you should be dynamically linking against. The docs state "There are known incompatibilities between the Python module and versions of the

[Distutils] Re: Three clarification questions about PEP 425 and PyPy3

On Fri, 31 Aug 2018 at 09:41, Paul Moore wrote: > My comment about wildcarding is basically a forlorn hope that if we > can't be sure what we're getting, maybe the best we can do is say > "well, py3-*-* sounds like it might work, and there's nothing better, > so let's give it a go". But if we

[Distutils] Re: What are reasonable compatibility tags? (was: Three clarification questions about PEP 425 and PyPy3

On Fri, 31 Aug 2018 at 22:03, Brett Cannon wrote: > You can make your pure Python wheel have a py3-cp36m-* wheel name and you get > the version specification you want; there is nothing saying a wheel must have > extension modules if it specifies an ABI tag. Currently, that won't work, as pip

[Distutils] Re: Environment markers for GPU/CUDA availibility

> On 4 Sep 2018, at 01:51, Nick Coghlan wrote: > > On Mon., 3 Sep. 2018, 5:48 am Ronald Oussoren, > wrote: > > What’s the problem with including GPU and non-GPU variants of code in a > binary wheel other than the size of the wheel? I tend to prefer binaries