On Mon, Sep 3, 2018 at 4:51 PM, Nick Coghlan <[email protected]> wrote: > On Mon., 3 Sep. 2018, 5:48 am Ronald Oussoren, <[email protected]> > 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", even if that requires some more work in building >> binaries (such as including multiple variants of extensions to have >> optimised code for different CPU variants, such as SSE and non-SSE variants >> in the past). > > > As far as I'm aware, binary artifact size *is* the problem. It's just that > once you're automatically building and pushing an artifact (or an image > containing that artifact) to thousands or tens of thousands of managed > systems, the wasted bandwidth from pushing redundant implementations of the > same functionality becomes more of a concern than the convenience of being > able to use the same artifact across multiple platforms.
None of the links that Dustin gave at the top of the thread are about managed systems though. As far as I can tell, they all come down to one of two issues: given "tensorflow" and "tensorflow-gpu" are both on PyPI, how can (a) users automatically get the appropriate version without having to manually select one, and (b) other packages express a dependency on "tensorflow or tensorflow-gpu"? And maybe (c) how can we stop tensorflow and tensorflow-gpu from accidentally getting installed on top of each other. -n -- Nathaniel J. Smith -- https://vorpus.org -- Distutils-SIG mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/[email protected]/message/CVW7ZVMHJTY2LCQZ33KO3WJQJM76WNF3/
