Talk:Python package guidelines

From ArchWiki
Revision as of 21:20, 24 December 2018 by Lahwaacz (talk | contribs) (→‎Clarifying PYPI URLs: remove closed discussion)
Jump to navigation Jump to search

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


Shouldn't the install command be protected?

python install --root=$pkgdir/ || return 1

Tokland 09:47, 26 July 2009 (EDT)

If a program fails to install, the install script probably shouldn't ignore such a critical error. For example, if something is wrong with the install script itself, then the installation probably should abort. Hiding such errors behind a || return 1 statement probably does not make sense. Am I missing something? Ichimonji10 (talk) 03:23, 25 June 2014 (UTC)
That's not even how (modern) makepkg works. The user-supplied build/package/etc functions are run with errexit, so any failing command will automatically abort the package. -- Eschwartz (talk) 18:05, 4 December 2018 (UTC)

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)