Mailman 3 September 2018 - Distutils-SIG

Re: disable building wheel for a package
by Jeroen Demeyer Sept. 15, 2018

Sept. 15, 2018

On 2018-09-14 18:36, Paul Moore wrote: > And actually, https://packaging.python.org/guides/distributing-packages-using-setuptools/… > is a reasonably clear explanation of the current behaviour I actually rewrote that paragraph recently, so I'm glad that you find it reasonably clear :-) But indeed, user installations should be mentioned.

2 1

Re: disable building wheel for a package
by Jeroen Demeyer Sept. 14, 2018

Sept. 14, 2018

On 2018-09-14 16:39, Paul Moore wrote: > My understanding (and I'm not an expert here, so hopefully someone > else will confirm or correct) is that yes, the data directory is > installed to "the installation root", which is $VIRTUAL_ENV for a > virtualenv, and "something else" for non-virtualenvs (I think it's / > on Unix and sys.prefix on Windows, no idea what happens for user > installs). More precisely: it's always sys.prefix for non-user installs (which is "/usr" not "/" on my system). For user installs, it's site.USER_BASE which is "/home/jdemeyer/.local" for me. I think that this works great, I see nothing to fix here (except being more explicit that absolute paths don't work). Jeroen.

3 2

Re: disable building wheel for a package
by Jeroen Demeyer Sept. 14, 2018

Sept. 14, 2018

On 2018-09-14 15:49, sashk wrote: > Do I understand correctly, that when using relative paths in the > data_files and installing package into virtual environment, > installation prefix is sys.prefix and it is the same as $VIRTUAL_ENV? Indeed, unless you specifically configure things in a non-default way. So you just need to replace absolute paths by paths relative to $VIRTUAL_ENV and your problem will be solved.

1 0

disable building wheel for a package
by sashk Sept. 14, 2018

Sept. 14, 2018

4 5

Environment markers for GPU/CUDA availibility
by Dustin Ingram Sept. 11, 2018

Sept. 11, 2018

Hi all, trying to pull together a few separate discussions into a single thread here. The main issue is that currently PEP 508 does not provide environment markers for GPU/CUDA availability, which leads to problems for projects that want to provide distributions for environments with and without GPU support. As far as I can tell, there's been multiple suggestions to bring this issue to distutils-sig, but no one has actually done it. Relevant issues: (closed) "How should Python packages depending on TensorFlow structure their requirements?" https://github.com/tensorflow/tensorflow/issues/7166 (closed) "Adding gpu or cuda specification in PEP 508" https://github.com/python/peps/issues/581 (closed) "More support for conditional installation" https://github.com/pypa/pipenv/issues/1353 (no response) "Adding gpu or cuda markers in PEP 508" https://github.com/pypa/interoperability-peps/issues/68 There is now a third-party project which attempts to amend this for tensorflow (https://github.com/akatrevorjay/tensorflow-auto-detect) but this approach is somewhat fragile (depends on version numbers being in sync), doesn't directly scale to all similar projects, and would require maintainers for a given project to maintain _three_ separate projects, instead of just one. I'm not intimately familiar with PEP 508, so my questions for this list: * Is the demand sufficient to justify supporting this use case? * Is it possible to add support for GPU Environment markers? * If so, what would need to be done? * If implemented, what should the transition look like for projects like tensorflow? Thanks! D.

10 22

Should an sdist/MANIFEST.in include docs and tests?
by Segev Finer Sept. 11, 2018

Sept. 11, 2018

What should really be included in an sdist via MANIFEST.in? Besides the obvious files required for a functioning package (Anything not caught by the default rules required for the package to function that is) and obviously LICENSE.txt and similar. A package's source tree, more often than not, includes other files such as documentation, tests, examples, a random assortment of other text files, etc. Should docs & tests, in particular, be included in an sdist via MANIFEST.in? Should other files be added too? Or maybe the sdist should be kept to a minimum? This is not clearly discussed in the packaging guide: https://packaging.python.org/guides/distributing-packages-using-setuptools/…. The sampleproject (https://github.com/pypa/sampleproject) does seem to include tests (Well a no-op test) and doesn't include them in the sdist.

9 12

Oct 27-28: Bloomberg sponsoring packaging sprint
by Sumana Harihareswara Sept. 10, 2018

Sept. 10, 2018

The weekend of October 27-28, simultaneously in London, UK and New York City, USA, Bloomberg will host a Python packaging and distribution tools event. Please mark your calendars! If you live in North America or Europe and would need assistance to attend this as a mentor/helper, watch for more details in July. If you live outside of the US or UK and would need an invitation letter to get a visa to travel to one of these sprints, please write to Kevin P. Fleming at Bloomberg, kpfleming AT bloomberg DOT net, and he'll start setting you up. Details: Thanks to Bloomberg for their generosity. They're already a Platinum PSF sponsor, and they'll host this, pay for a maintainers'/mentors' dinner the night before, provide clusters of cloud virtual machines for the attendees to use, and book and pay for some contributors' lodging and travel. This'll be an opportunity to advance Python packaging/distro tools, teach new contributors (including many Bloomberg employees), and yeah, if you want to get to know Bloomberg for career reasons, that too. :) We hope mentors can arrive Thursday night 25 Oct, do prep, setup, and dinner on Friday, then participate Sat-Sun, then leave Sunday evening or Monday. We'll be putting more details on these lists (distutils-sig and pypa-dev) and at https://wiki.python.org/psf/PackagingSprints . Thanks to Bloomberg folks Mario Corchero and Henry Kleynhans in London and Kevin P. Fleming in New York City for coordinating this, and thanks especially to Mario and to Paul Ganssle for suggesting it! -- Sumana Harihareswara Changeset Consulting https://changeset.nyc

2 2

Three clarification questions about PEP 425 and PyPy3
by Brett Cannon Sept. 4, 2018

Sept. 4, 2018

I noticed that for PyPy3, the tag triples considered compatible were (roughly; trimmed out the long list of macOS versions): [('pp360', 'pypy3_60', 'macosx_10_13_x86_64'), ('pp360', 'none', 'macosx_10_13_x86_64'), ('py3', 'none', 'macosx_10_13_x86_64'), ('pp360', 'none', 'any'), ('pp3', 'none', 'any'), ('py360', 'none', 'any'), ('py3', 'none', 'any')] Now the first question I have is about ('pp3', 'none', 'any'). Is this meant to be a generic thing for any interpreter of the interpreter implementation and major version, or is this special to CPython and PyPy3? Question two is why isn't there a ('py35', 'none', 'any') or ('py34', 'none', 'any') and older to py30 after py3 like there is for CPython? Seems like if they are just source then they should be compatible as much as CPython. Question three is why isn't there a ('py35', 'none', 'macosx_10_13_x86_64') for PyPy3 or CPython 3.7? I can't figure out what a Python- and platform-specific wheel but agnostic to API wouldn't ever work? And I'm assuming ('py360', 'none', 'any'), isn't legitimate since that makes no sense. ;)

8 35

(no subject)
by youtube.com/[whatItSaysHere] [whatItSaysHere] Sept. 4, 2018

Sept. 4, 2018

null

1 0