On 2017-09-28 19:59:12, Dmitry Shachnev wrote: > On Thu, Sep 28, 2017 at 08:27:20AM -0400, Antoine Beaupré wrote: >> > And moving Python 3 packages to /usr/bin/sphinx3-build or something like >> > that will mean diverging from upstream (see below). >> >> Note that we already diverge from upstream in numerous places in Python, >> first and foremost in the naming of the Python binary itself. > > How do we diverge there? In my opinion we follow PEP 394 quite closely: > https://www.python.org/dev/peps/pep-0394/
Ah. Oops. :) I guess I was thinking of virtualenvs... >> > Good suggestion, I have submitted a pull request upstream: >> > https://github.com/sphinx-doc/sphinx/pull/4092 >> >> Excellent - I meant to do that but ran out of time writing the email in >> the first place. :) >> >> I see, however, it's not getting too much traction.. But they have a >> fair point - I didn't realize there was a difference between variables >> from the environment and from the commandline in Make. Maybe it's good >> enough as it is then. > > It is not ‘they’, it is our Simon :) He also replied on this mailing list, > just did not CC you. Oops again. :) I replied there as well. [...] >> This is why I mention pybuild: maybe *that* is where docs should be >> built? I am not sure. In any case, I feel there's a shim missing here, >> and there's a good occasion to leverage the automation we have to >> generate proper build deps and build-time commands. > > Maybe pybuild can do this, but it then needs to make some assumptions > about the doc source path, build path, wished formats, etc. For finding source > path it can probably use something like this: > > https://github.com/sphinx-doc/sphinx/blob/stable/sphinx/setup_command.py#L111 > > But it is up to pybuild maintainer (Piotr) to decide whether he wants this > feature or not. Well, it would sure be nice to have some place for this, of course. [...] >> > Also there is no such thing as sphinx3-build upstream (unlike other >> > packages >> > that follow this convention). So all upstream projects will try to use >> > sphinx-build, not sphinx3-build, even if they are Python 3 only. And if you >> > override this command anyway, you can use two existing ways, I don’t see a >> > need for the third one. >> >> The reasoning here is that is is more discoverable, namely through >> commandline completion, and is consistent with the /usr/bin/python* >> binary naming conventions. > > I have just figured out that there *is* bash completion for python3 -m > syntax. What i meant is that "sphinx<TAB>" doesn't show there is a python2 vs python3 version. [...] > Now it is explicit: > https://anonscm.debian.org/cgit/python-modules/packages/sphinx.git/commit/?id=5b2efffcaae8c915 Excellent, thanks again. A. -- Pour marcher au pas d'une musique militaire, il n'y a pas besoin de cerveau, une moelle épinière suffit. - Albert Einstein
