Mailman 3 January 2020 - Distutils-SIG

Packaging Summit 2020: Save the Date!
by Paul Ganssle Jan. 15, 2020

Jan. 15, 2020

Greetings one and all! Each year millions of eyes around the world eagerly wait at their computer with baited breath to learn the timing of the most fabulous, extravagant, decadent and hyperbolically oversold event of the year: The Python Packaging Summit. While most of the details aren't finalized (and in fact basically no details are finalized), in the interest of giving those who would like to attend a chance at some additional notice on their travel plans, we have established that the date of the summit: *Thursday, 16 April 2020* (the day before the first PyCon talk day). For the past two years we've unofficially held our mini-summit on the first day of PyCon Sprints, but given that this summit is of particular interest to maintainers - many of whom would like to spend the first day of sprints actually sprinting - we have decided to run the summit on the tutorials day parallel to the Education Summit. We have applied for a spot in the Hatchery program, but even if we are not accepted as an official PyCon evenat, we will make arrangements to run the summit off-site on that day. For those unaware of the nature of the summit, you may want to pay attention to the "hyperbolically oversold" portion of my description less than the "decadent" and "extravagant" portions. The purpose of the summit is to get a bunch of people interested in Python Packaging together to discuss and coordinate on important topics in packaging and how we can move them forward. If you are on the fence about joining and want to know more, here are some detailed notes taken at the summit last year: https://docs.google.com/document/d/1Wz2-ECkicJgAmQDxMFivWmU2ZunKvPZ2UfQ59zD… As I mentioned earlier, we have finalized essentially *no* details of this summit other than the date. I do not know how many people will be able to attend or by what mechanism we will prioritize attendance at the summit if there is limited space. In the coming months please keep an eye out for: * Registration details (if such a thing is deemed necessary) * A call for topic suggestions * Voting on how to prioritize topic suggestions Looking forward to seeing you all there! Paul

4 3

With setuptools, “optional” C extension module error is fatal
by Dan Stromberg Jan. 15, 2020

Jan. 15, 2020

Hi folks. (There's a copy of this message on stack overlfow at https://stackoverflow.com/questions/59522262/with-setuptools-optional-c-ext… ) I'm putting a little time into getting my treap module (like a dict, but always sorted by key) working with distutils. I want it to be able to compile and install the Cython version from an included .c file, or to fall back on a pure python version if that fails. I'm currently using: setup( name='treap', py_modules=[ 'treap', 'py_treap', 'nest', ], # ext_modules=cythonize("pyx_treap.pyx"), ext_modules=[Extension('pyx_treap', ['pyx_treap.c'], optional=True)], # setup_requires=[ # 'Cython' # ], version=version, description='Python implementation of treaps, ) ...plus a few more options to setup that don't seem relevant. If I run python3.6 setup.py build, I get: running build running build_py creating build creating build/lib.linux-x86_64-3.6 copying treap.py -> build/lib.linux-x86_64-3.6 copying py_treap.py -> build/lib.linux-x86_64-3.6 copying nest.py -> build/lib.linux-x86_64-3.6 running build_ext building 'pyx_treap' extension creating build/temp.linux-x86_64-3.6 x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -g-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time-D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.6m -c pyx_treap.c -o build/temp.linux-x86_64-3.6/pyx_treap.o pyx_treap.c:4:10: fatal error: Python.h: No such file or directory #include "Python.h" ^~~~~~~~~~ compilation terminated. error: command 'x86_64-linux-gnu-gcc' failed with exit status 1 So it seems like despite using Extension('pyx_treap', ['pyx_treap.c'], optional=True), the cython version is not optional. Am I missing something? Why doesn't it just continue with the pure python modules? I realize I could install python3.6-dev or similar to eliminate the error, but I don't want to assume the user knows that. Thanks!

1 1

setup.py test deprecation timeline
by bmw＠eff.org Jan. 15, 2020

Jan. 15, 2020

Is there an ETA for when setuptools is going to break the test subcommand? It would be useful for me to know how long I have to stop using tests_require and to help OS package maintainers migrate to a new way of running tests. Thanks for any info! Brad Warren

2 1

python3 prefixed package RPMs
by Ratliff, John Jan. 8, 2020

Jan. 8, 2020

It seems RHEL/CentOS prefers python3-{package}.rpm as the RPM name, with the python3 part of the package name. If I add python3 as a name prefix in setuptools, it works, but it changes the egg-info directory to have the python3- prefix as well, which is not what I've seen in other python RPMs in CentOS. Is there a way I can add the python3 prefix when doing python3 setup.py bdist_rpm? Thanks. --John

2 1