Package Details: python37 3.7.5-2

Git Clone URL: https://aur.archlinux.org/python37.git (read-only)
Package Base: python37
Description: Major release 3.7 of the Python high-level programming language
Upstream URL: https://www.python.org/
Keywords: python python3
Licenses: custom
Submitter: 5long
Maintainer: 5long
Last Packager: 5long
Votes: 9
Popularity: 7.18
First Submitted: 2019-11-14 21:23
Last Updated: 2019-11-15 13:58

Pinned Comments

5long commented on 2019-11-20 15:36

I'm seriously considering bumping the pkgrel for a bunch of changes:

  • --with-threads is no longer recognized, which should be removed. No questions with that.

  • Enable --with-ensurepip. For now, I don't see building --without-ensurepip could yield any benefits. The ensurepip module and .whls of setuptools & pip are installed anyway even when building --without-ensurepip. It's just the bundled .whls might become out of date in the future, which doesn't meet Arch's "only run latest software" guideline.

  • Running tests (either in check() or building with --enable-optimizations) seems to be causing trouble for some people. Building with --enable-optimizations claims to boost performance for 10% ~ 20% (1). Personally I don't quite care about Python's performance on my dev machine that much. Another problem is: the test suite could run for as long as 30+ minutes, which is pretty slow comparing with other AUR packages that I use. But I'm guessing that people might expect this package to be "just like python in the official repo", which is built with --enable-optimizations enabled. So I still haven't decided on this yet.

Latest Comments

1 2 Next › Last »

PeteAnderson commented on 2019-12-06 22:15

I found this in the makefile:

# The task to run while instrumented when building the profile-opt target.
# We exclude unittests with -x that take a rediculious amount of time to
# run in the instrumented training build or do not provide much value.
PROFILE_TASK=-m test.regrtest --pgo

But whoever wrote the comment must have forgotten to actually add -x to the command. So I added this to PKGBUILD in prepare():

  sed -i -Ee 's|(PROFILE_TASK=-m test.regrtest --pgo)|\1 -x|' Makefile

This avoids running the tests while still building an optimized build, and gave me a functional 3.7 build in about 10 minutes.

yurikoles commented on 2019-11-27 11:29

sorry for false-flag

5long commented on 2019-11-25 12:10

@Fuzzy: Yes, building with --enable-optimizations does run tests due to PGO optimization. Maybe I'll just remove this ./configure option in the next version of PKGBUILD (but I haven't decided yet).

About the missing _ctypes module: you can try building the package in a clean chroot, which is explained in the wiki: https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_clean_chroot This isn't trivial to setup and it will take up a fair bit of disk space. But it should solve most problems of "package builds differently on different machines".

Fuzzy commented on 2019-11-25 04:49

Hi! First, thanks for this package. I also ran into troubles with last arch upgrade... But: I don't see check() section in my PKGBUILD but somehow tests are ran. There are several failed tests but worse - 'test_socket' gets stuck. I had removed --enable-optimizations and yay built and installed it successfully. At first look it works but now I have another error: No module named '_ctypes' (pacman shows that I have libffi installed...)

5long commented on 2019-11-20 15:36

I'm seriously considering bumping the pkgrel for a bunch of changes:

  • --with-threads is no longer recognized, which should be removed. No questions with that.

  • Enable --with-ensurepip. For now, I don't see building --without-ensurepip could yield any benefits. The ensurepip module and .whls of setuptools & pip are installed anyway even when building --without-ensurepip. It's just the bundled .whls might become out of date in the future, which doesn't meet Arch's "only run latest software" guideline.

  • Running tests (either in check() or building with --enable-optimizations) seems to be causing trouble for some people. Building with --enable-optimizations claims to boost performance for 10% ~ 20% (1). Personally I don't quite care about Python's performance on my dev machine that much. Another problem is: the test suite could run for as long as 30+ minutes, which is pretty slow comparing with other AUR packages that I use. But I'm guessing that people might expect this package to be "just like python in the official repo", which is built with --enable-optimizations enabled. So I still haven't decided on this yet.

maria.v commented on 2019-11-20 04:29

@leandro: for pip3.7 you can edit PKGBUILD to replace --without-ensurepip with --with-ensurepip and rebuild the package.

5long commented on 2019-11-18 14:45

@MuffinBomber: I'm no expert in building Python. Maybe the test case you are stuck on is a different test case. Not the one removed in https://bugs.python.org/issue34587.

And yes: by removing the line of --enable-optimizations from PKGBUILD, a clean rebuild (with makepkg -Csf) no longer runs the tests on my machine.

MuffinBomber commented on 2019-11-18 11:23

When building the package 'test_socket' gets stuck. Is there a way to solve this or should I just remove the '--enable-optimizations' line and skip the tests completely (while also dealing with slower executing code)?

EDIT: According to https://bugs.python.org/issue34587 that test was removed from 3.7, but somehow it is still present?

Lucki commented on 2019-11-16 14:55

Thanks for your insights. I'm no expert especially with python.

My package doesn't run with 3.8 anymore and upstream is (nearly) dead. Looks like this will be a bigger task to get it run again.

5long commented on 2019-11-16 13:58

@Lucki: I'm not quite sure if this pacakges should claim provides=... in its PKGBUILD.

Python packages are, in a way, built for a specific version of Python. Most of their files are installed into /usr/lib/pythonX.Y and they won't run under a different version of Python. If a package only runs under Python 3.7, I'd suggest it claims python37 as its dependency. The Python version is hard-coded in the package name already.

Another problem is: only Arch's official python package provides /usr/bin/python. Other packages must not do that. Even if python37 does provides=python<3.8, any python scripts starting with #!/usr/bin/python won't run. So the provides=... just become a false promise. This whole situation may be resolved once pacman implements an alternatives system (which is being discussed here: https://lists.archlinux.org/pipermail/pacman-dev/2019-October/023691.html) in the future.

But still, this is my first time writing a "serious" PKGBUILD. And by writing I mean "copying from official repo and python36". What I've said above may very well be wrong. Feel free to point out any mistakes.