Talk:Python package guidelines

From ArchWiki
Revision as of 18:05, 4 December 2018 by Eschwartz (talk | contribs) (→‎Build: re; close)
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)

Clarifying PYPI URLs

The footnote about the "new stable scheme" directs to a Bitbucket login page. Could someone with access kindly post the new, stable scheme so users can access it here without referring to a bug tracker comment for it? At present it simply says that PKGBUILD source arrays "should now use the following URL templates." I found that confusing and think with a quick example all would be clear!

Also, I think a footnote was intended after the legacy URL example (it says "<footnote>").

As an aside, I kind of think the why behind using the URL changes is irrelevant and not that helpful. Users are likely coming to the page to find out what to use in their packages, or possibly to understand a breakage where the change hasn't trickled down. In that case, maybe mention that the format changed in 2016 (with a reference) but stick to the current, recommended format. Just my thought after reading it for the first time. Jwhendy (talk) 04:39, 3 January 2018 (UTC)

The Bitbucket links are completely broken as pypa have disabled issue tracking entirely over there, so I've migrated the links to github (issue comments were auto-migrated so it's all good). I'm not yet sure whether they "should" be there, but at least they're no longer broken...
The <footnote> was added in [1] but I'm not sure what it was meant to do. -- Eschwartz (talk) 06:12, 3 January 2018 (UTC)
With the change of domain from to, the old scheme was adding even more confusion. I've removed mention of the old scheme, only leaving info about the current situation. Lonaowna (talk) 21:02, 16 June 2018 (UTC)