Page MenuHomeSolus

Initial commit of python-autopep8
AbandonedPublic

Authored by doc-E-brown on Sep 23 2017, 2:48 PM.
Tags
None
Referenced Files
F11054285: D1067.id2568.diff
Fri, Aug 11, 12:37 AM
F11054284: D1067.id.diff
Fri, Aug 11, 12:37 AM
F11054283: D1067.id2826.diff
Fri, Aug 11, 12:37 AM
F11054282: D1067.id2607.diff
Fri, Aug 11, 12:37 AM
F11054281: D1067.id2614.diff
Fri, Aug 11, 12:37 AM
F11038136: D1067.diff
Wed, Aug 9, 10:03 PM
F10915295: D1067.id2826.diff
Jul 8 2023, 6:23 AM
F10816293: D1067.diff
Jun 1 2023, 1:24 AM

Details

Reviewers
DataDrake
Group Reviewers
Triage Team
Maniphest Tasks
T3690: autopep8
Summary

The inclusion of autopep8 fixes T3690

Test Plan

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

This revision is now accepted and ready to land.Sep 24 2017, 1:46 PM

License should be just MIT not MIT License (as per SPDX identifier), and also, why does this need networking?

Ah, missed that. Thanks @EP01

This revision now requires changes to proceed.Sep 24 2017, 4:36 PM
doc-E-brown edited edge metadata.

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!

This revision now requires changes to proceed.Oct 7 2017, 1:17 AM
doc-E-brown edited edge metadata.

Renamed Python3 script autopep8-3 to autopep83

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.

In D1067#18274, @EP01 wrote:

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!

All Good @EP01 ! No worries there.

This revision is now accepted and ready to land.Nov 24 2017, 4:40 PM

Can you rename this to just autopep8? After thinking about it the prefix is really not necessary.

This revision now requires changes to proceed.Dec 17 2017, 4:22 PM

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 ?

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.