Difference between revisions of "Talk:Python package guidelines"

From ArchWiki
Jump to: navigation, search
(Python version directories: re)
 
(8 intermediate revisions by 6 users not shown)
Line 1: Line 1:
There is going to be an official policy drafted to deal with .pyc/.pyo files. See: http://wiki.archlinux.org/index.php/User:Allan/Python_Packaging_Policy
+
There is going to be an official policy drafted to deal with .pyc/.pyo files. See: https://wiki.archlinux.org/index.php/User:Allan/Python_Packaging_Policy
  
 
= Build =
 
= Build =
Line 10: Line 10:
  
 
[[User:Tokland|Tokland]] 09:47, 26 July 2009 (EDT)
 
[[User:Tokland|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 <code>|| return 1</code> statement probably does not make sense. Am I missing something? [[User:Ichimonji10|Ichimonji10]] ([[User talk:Ichimonji10|talk]]) 03:23, 25 June 2014 (UTC)
 +
 +
== tests directory ==
 +
 +
The article states that one shouldn't install a "tests" directory. My package however, after running through setup.py, 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 setup.py 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.
 +
: [[User:Eschwartz|Eschwartz]] ([[User talk: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 {{ic|python -c 'import tests'}}, and your code is imported, that's bad; If I install your package and execute {{ic|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 [https://github.com/PulpQE/pulp-smash/ this package]. The top-level "tests" directory is not — as of [https://github.com/PulpQE/pulp-smash/pull/458 this PR] — installed by setup.py, and therefore produces no namespace conflicts. The "pulp_smash/tests" directory is installed by setup.py and available as "pulp_smash.tests", and therefore produces no namespace conflicts. [[User:Ichimonji10|Ichimonji10]] ([[User talk:Ichimonji10|talk]]) 21:56, 19 December 2016 (UTC)
 +
 +
:: I'm experiencing these issues with [https://aur.archlinux.org/packages/python-pendulum/ python-pendulum] and [https://aur.archlinux.org/packages/python-pytzdata/ 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? --[[User:Johnpatcher|Johnpatcher]] ([[User talk: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/.
 +
 +
[[User:Z3ntu|Z3ntu]] ([[User talk:Z3ntu|talk]]) 12:35, 24 January 2017 (UTC)
 +
 +
:The {{ic|/usr/lib/python3/}} path does not work: {{bc|<nowiki>
 +
>>> import sys
 +
>>> sys.path
 +
['', '/usr/lib/python36.zip', '/usr/lib/python3.6', '/usr/lib/python3.6/lib-dynload', '/home/lahwaacz/.local/lib/python3.6/site-packages', '/usr/lib/python3.6/site-packages']
 +
</nowiki>}} Hence it is a bug and should be reported on the bug tracker. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:46, 24 January 2017 (UTC)

Latest revision as of 12:47, 24 January 2017

There is going to be an official policy drafted to deal with .pyc/.pyo files. See: https://wiki.archlinux.org/index.php/User:Allan/Python_Packaging_Policy

Build

Shouldn't the install command be protected?

python setup.py 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)

tests directory

The article states that one shouldn't install a "tests" directory. My package however, after running through setup.py, 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 setup.py 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 setup.py, and therefore produces no namespace conflicts. The "pulp_smash/tests" directory is installed by setup.py 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/python36.zip', '/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)