Talk:Python package guidelines

From ArchWiki
Jump to navigation Jump to search

There is going to be an official policy drafted to deal with .pyc/.pyo files. See:

tests directory

The article states that one shouldn't install a "tests" directory. My package however, after running through, contains such a directory. What is the recommended way to deal with this? Can this directory be deleted? Couldn't find a clue in other Python packages I've looked at, so can someone maybe point me in the right direction?

You should probably delete it from "${pkgdir}". I don't know of any reason to have such a directory, unless it contains unittests for the module. Which probably means upstream should be advised to fix their because there is no reason to run unittests on an installed module, and the module itself certainly shouldn't rely on methods hidden in the unittests...
I don't actually know of any misbehaving modules to point to which violate that rule though.
Eschwartz (talk) 18:52, 19 December 2016 (UTC)
To the best of my knowledge, the recommendation is designed to prevent namespace conflicts. If I install your package and execute python -c 'import tests', and your code is imported, that's bad; If I install your package and execute python -c 'from your_package import tests', and your code is imported, that's fine. Getting this right is a little tricky. For an example of Python code that sidesteps these issues, see this package. The top-level "tests" directory is not — as of this PR — installed by, and therefore produces no namespace conflicts. The "pulp_smash/tests" directory is installed by and available as "pulp_smash.tests", and therefore produces no namespace conflicts. Ichimonji10 (talk) 21:56, 19 December 2016 (UTC)
I'm experiencing these issues with python-pendulum and python-pytzdata, both of which seem to install a global tests directory. Not too familiar with Python packaging, so I'm not sure if it is ok to simply delete those directories? --Johnpatcher (talk) 06:54, 20 December 2016 (UTC)

Python version directories

For example debian packaging guidelines dictate that python files go into /usr/lib/pythonX/ and OpenSUSE wants files to go into /usr/lib/pythonX.Y/.

Arch should have a clear guideline where packaged files go into. Most packages have their python files in /usr/lib/pythonX.Y/ but the package openimageio has python files in /usr/lib/python3/.

Z3ntu (talk) 12:35, 24 January 2017 (UTC)

The /usr/lib/python3/ path does not work:
>>> import sys
>>> sys.path
['', '/usr/lib/', '/usr/lib/python3.6', '/usr/lib/python3.6/lib-dynload', '/home/lahwaacz/.local/lib/python3.6/site-packages', '/usr/lib/python3.6/site-packages']
Hence it is a bug and should be reported on the bug tracker. -- Lahwaacz (talk) 12:46, 24 January 2017 (UTC)

Remove pip section in favor of wheels section?

I can’t come up with any reason to use pip other than installing wheels, and wheels are just as easily installed by

  1. Unzipping them into the $pkgdir
  2. Creating a little wrapper scripts for all console_scripts it provides (Which can be done manually or using install-wheel-scriptsAUR)

Do you agree? – flying sheep 18:08, 12 March 2019 (UTC)

pyproject2setuppy as dephell alternative for flit/poetry

When packaging first flit/poetry packages for Gentoo, I've written pyproject2setuppy to avoid the dependency hell involved in other existing solutions (read: I really didn't want to have to package dephell). Perhaps you'd be interested in using it in place of dephell. It's ~200 lines of Python with the only dependency being toml, so it's much lighter on the packager. When the new build systems become more popular, it may also help you avoid circular dependencies. MGorny (talk) 05:41, 4 May 2020 (UTC)