default name for co-installed python2 & python3 pyflakes

I believe in debian we are settling for py3flakes, because of other similar python helper commands that use "py" as python2 prefix, and "py3" as python3 prefix.

This can be done like so: https://bitbucket.org/tarek/flake8/issue/85/set-up-version-specific-installations

It would create two binaries, `pyflakes` and `pyflakes-3.2` (for example). Would this be satisfactory for debian?

@xnox "in Debian" it's actually good to ask the opinion of the people who has their name next to the package - which you fail to do all the time. How about talk to package uploaders first?

@Sandro Tosi
The specific naming has been discussed extensively with the debian python team DDs on #debian-python.
Please, lets continue that discussion in the team's communication.

@ Ian
yes and no, we also want to avoid gaining an explicit dependency on each python3.X package at build-time, when later python3.X+1 can become default thus requiring an useless no-change upload to fix up the dependencies.

This is more for the name of the script that will have /usr/bin/python3 shebang and that should be stable (e.g. point to default python3 version regardless of which exact version that symlink points to)

I am a dd, and I'm one (for the time being) of the maintainer of pyflakes, and I was not involved *at all* in those discussion, and I bet nor of the other maintainers. sure keep discussing it whatever you want, that doesn't change the fact you're not involving any of the real people doing maintenance work on the package - well done

Why would both versions need to be installed? It would seem fine to me to just ship the version that uses python3 only, once python3 support in pyflakes is stable, and one that uses python2 prior to that.

I don't see any reason to ship two conflicting versions of the script.

Nevermind. Florent just pointed out the fact that the AST parsing will give inconsistent results if parsing code written for Python 2 is done inside a pyflakes running under python3.

Given all this, I think one of the following would be the best choice, for creating consistency across projects which need to install multiple scripts for different Python versions, and to clarify that it's for Python 3 instead of Python 2:

1) pyflakes-py3
2) py3-pyflakes

Going with the former would probably be better, as prefixing everything with py3- could create an undesirable amount of scripts showing up when trying to tab complete a command.

We have many packages in the archive that build-depend on pyflakes and run it at build-time.
Recent pyflakes behaves differently depending on whether it's invoked with python3 vs python2 interpreter and thus if /usr/bin/pyflakes shebang is suddently changes to python3 many packages will start failing their python2 portion of the builds.
Sure enough we can demand as a policy to invoke pyflakes as pythonX.Y /usr/bin/pyflakes when run during builds, but it's a new not strictly needed change. Many people want a py3 default script to manually invoke from command line using a sensible/easy tab completion.

@dobey
BTW we already have:
- py3clean py3compile py3_compilefiles py3versions
- py.test-3 pygettext3 pydoc3

A mixture of everything! *sigh*

So in spite of the squabble here, the typical way that python developers manage this is as I described. How Debian and Ubuntu manages this, I believe, belongs in a separate discussion that is not here. That is more of a packaging issue than a pyflakes issue with all due respect.

Pursue the debate on <email address hidden> if needed. Thanks.

FWIW, I don't like the pyfoo/py3foo varieties because it makes it harder to locate(1).

I just started a thread on python-dev for a general recommendation on the subject, perhaps leading to an informational PEP. Also, I just committed to Debian svn naming it pyflakes3. Yay for consistency.