The inclusion of autopep8 fixes T3690
Details
- Reviewers
DataDrake - Group Reviewers
Triage Team - Maniphest Tasks
- T3690: autopep8
After installing: enter autopep8 on the command line to execute
the autopep8 program using the Python2 interpreter. Enter autopep83
to execute the program using the Python3 interpreter. You can also test using
python -c "import autopep8"
python3 -c "import autopep8"
and no errors should be returned
Diff Detail
- Branch
- master
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
License should be just MIT not MIT License (as per SPDX identifier), and also, why does this need networking?
Updated as per review comments:
Changed MIT License to just MIT
Changed source from pypi to github location to allow for removal of networking
Sorry, one last thing, the order of the builddeps should be:
- pkgconfig(python3)
- python-setuptools
Packages obtained from pkgconfig come first, then explicitly named packages, both sorted alphabetically. pkgconfig(python) isn't needed as it's part of the base image.
And maybe append the python3 executable with -3 instead of 3 if the name already ends in a number. Don't know what the official stance on that is, just a personal preference.
Reordered build dependencies
Removed explicit requirement of pkgconfig(python) as is in base image
Renamed autopep83 to autopep8-3 for Python 3
@doc-E-brown let's keep the executable name autopep83 for python3.
@EP01 I appreciate the help, but please try not to create unnecessary work for others. Thanks!
Apologies for that @DataDrake and @doc-E-brown. As I said it's just a personal preference, and a similar convention is followed in R2642. I haven't been able to find a conclusive answer from PEPs or other distros on whether executables ending in a number should be treated differently; at least it's not as bad as Arch who have autopep8-python2 for their python2 version. Again, sorry for the extra work @doc-E-brown!
Arch Linux technically violates the PEP by having python3 as the primary python interpreter :)
Sorry for adding towards the confusion - but i thought the general rule was to append -3 if the python executable ended with a number otherwise just append 3.
For example in python-docutils there is binaries such as rst2html4 and rst2html5 so I append the python 3 versions with -3 to avoid confusion.
Can you rename this to just autopep8? After thinking about it the prefix is really not necessary.
Sorry to interfere here but it would be nice to make a clear statement about this because until now, I used to prefix all python packages with python-, perl packages with perl-, font packages with font-, etc. just because I saw it is a kind of "de facto" naming standard. Shall I keep on doing this or should I drop the prefix for new patch submission ?
The point of these prefixes is to avoid name collisions. For example python-pathtools and perl-pathtools would have the same name without a prefix. It just so happens that nearly every python and perl package is a library that is later used by an application with a unique name (hence no prefix). Fonts and themes are prefixed to deal with the odd occasion that those also end up with the same name.
In this case however, autopep8 is an application with a unique name (PEP is always Python) and not a library, so it makes the most sense to follow the upstream naming convention.
Abandoning due to lack of movement in over 30 days. Please feel free to re-open after addressing the issues previously raised.