Mailman 3 - Distutils-SIG

Dating
by johncoli900＠gmail.com 10 Feb '20

10 Feb '20

The <a href="https://tinderdatingsites.com/">tinder dating site</a> is used to meet sexy girls whom you can have a healthy relationship. If you are single and wanted to have a relationship then don't worry you can use <a href="https://adultfriendfinderz.co/">adult friend finder</a> to meet hot people.

1 0

Troubles with pip
by George R Goffe 09 Feb '20

09 Feb '20

Hi, I'm very new to this python community. This system is a FedoraCore 32 x86_64 (Rawhide) freshly installed. I was reading about beautifulsoup... and was directed to use pip "pip install beautifulsoup4". I got nothing. strace -xvfp <pid of pip> shows that pip is in (hung?) in the recvfrom(...) system call. Is pip trying to "talk" with a site that's down? Perhaps I'm not doing something correctly? Thanks for your help, George...

2 1

"requirement" corner case
by Gordon Messmer 30 Jan '20

30 Jan '20

I'm working on tools to convert python packaging data to rpm spec files. Most of the conversions are relatively straightforward, but there's an odd corner case with ">" and versions ending in ".*". That combination is parsed as a valid specification, but oddly, it seems to behave the same as ">= version", as demonstrated below. Is this intentional, or is it a byproduct of parsing ">1.0.*" as a LegacySpecifier? Should I convert ">1.0.*" into ">=1.0" and mimic the current behavior, or into something else, like "> 1.0", or ">= 1.1"? >>> pkg_resources._vendor.packaging.requirements.Requirement('cairocffi > 1.0.*,< 1.0.1').specifier._specs frozenset({<LegacySpecifier('>1.0.*')>, <Specifier('<1.0.1')>}) >>> '1.7' in pkg_resources.Requirement.parse('foo>1.7.*') True

2 3

Virtualenv 20.0.0 beta1 is available
by Bernat Gabor 28 Jan '20

28 Jan '20

More information available at https://discuss.python.org/t/virtualenv-20-0-0-beta1-is-available/3077

1 0

pip 20.0 release!
by Pradyun Gedam 21 Jan '20

21 Jan '20

Hello everyone! On behalf of the PyPA, I am pleased to announce that pip 20.0 has been released. This release contains quite a lot of changes (you can see the full list here <https://pip.pypa.io/en/stable/news/>). The highlights for this release are: - Shorter filenames in output, when installing from PyPI. - Automatic fall back to user installs, when main site-packages directory is not writable and user installs are allowed. - Significantly improved wheel building and wheel caching. - Significantly reworked PEP 425 (binary compatibility tag) computation. - Better handling of system packages in virtual environments created with `venv` (PEP 405). - Older pip entry points have been reinstated temporarily, to aid users with stale wrapper scripts. We expect that upgrading to this version of pip, would be painless for most users. We recommend that users test the release before deploying in production, as with any other software release. The pip development team is extremely grateful to everyone in the community for their contributions. Thanks to everyone who put so much effort into the new release. Many of the contributions came from community members, whether in the form of code, participation in design discussions and/or bug reports. Cheers, Pradyun

1 0

localization, accessibility, & security progress on PyPI
by Sumana Harihareswara 17 Jan '20

17 Jan '20

I've just posted a final progress report on Discourse about the last month of Open Tech Fund-supported progress on PyPI's localization and accessibility features. Including a screenshot and a bar graph! https://discuss.python.org/t/pypi-localization-accessibility-progress/2284/4 We've finished our OTF-funded accessibility & internationalization work. And sometime this month people will be able to use PyPI in Brazilian Portugese and Japanese! -- Sumana Harihareswara PyPI project manager Changeset Consulting https://changeset.nyc

1 1

Deal with pip setup.py name and rpm packaging
by Marco Favero 15 Jan '20

15 Jan '20

Hello, recently I started to develop a tool in python. I discovered pip and setuptool with setup.py. It's fantastic! I can provide packaging to pypi and to rpm all in a row. I follow these guidelines: - https://packaging.python.org/tutorials/packaging-projects/#generating-distr… - https://docs.python.org/3/distutils/builtdist.html?highlight=rpm - https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/ With %{?python_enable_dependency_generator} the RPM provides the dependecies itself. Fantastic! But how to force the developers to use consistent names? :D For instance these python-magic and redis client packages: https://pypi.org/project/python-magic https://pypi.org/project/redis/ use names which conflict with already existent rpm packages names. In particular, "redis" in rpm is the name of the Redis server package! If I make "bdist_rpm" of python Redis client and I "yum install" the package I damage my system deleting the Redis server! The Redis client developer says that he can't change the name because this will break existent installations: https://github.com/andymccurdy/redis-py/pull/385 I think this is not a good situation. Python environment should help to improve an "inconsistent" setup. As a result, I have to make bdist_rpm of the dependencies, then I have to install the source rpm, change the name in SPEC file and rebuild the rpm package. In my package I can't use %{?python_enable_dependency_generator}, because it uses the fault pypi names, I have to provide them myself. :( Thank you for reading this noise Have a fantastic python day Marco

2 2

Packaging Summit 2020: Save the Date!
by Paul Ganssle 15 Jan '20

15 Jan '20

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 14 Jan '20

14 Jan '20

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 14 Jan '20

14 Jan '20

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