Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sphinx.cmd.build Syntax Error #6470

Closed
kdschlosser opened this issue Jun 10, 2019 · 11 comments
Closed

sphinx.cmd.build Syntax Error #6470

kdschlosser opened this issue Jun 10, 2019 · 11 comments
Labels
Milestone

Comments

@kdschlosser
Copy link

kdschlosser commented Jun 10, 2019

Traceback
File "sphinx-2.1.0-py2.7.egg\sphinx\cmd\build.py", line 39
file=stderr)
^
SyntaxError: invalid syntax

To Reproduce

from sphinx.cmd.build import build_main

Expected behavior
No Syntax Error

Your project
python-openzwave
what I am working on has not yet been pushed to the repository

Environment info

  • OS: Windows 7 x64 SP1
  • Python version: 2.7.15
  • Sphinx version: 2.1.0
  • Sphinx extensions: didn't get that far into the build process
  • Extra tools: N/A

Additional context
What I am currently working on is making an extension for distutils "build_docs". I made it to use the exact same command line arguments as sphinx. This would make it easier to port if someone wanted to do the same as what I am doing. It also builds the conf.py file. I did have it working with an older version of Sphinx. I do not recall the exact version. The information I can provide is that build_main was directly accessible from the main sphinx module. example below shows how the older version worked.

import sphinx

sphinx.build_main()

I do not know if future.print_function has support in it for setting the file. This may be the only thing that needs to be added.

@kdschlosser
Copy link
Author

kdschlosser commented Jun 10, 2019

OK so I have just looked at the Pypi page for Sphinx. It states on the page python >= 3.5

But yet Pypi returns the URL for a wheel for 2.1.0 on python 2.x. easy_install is what setuptools uses to install requirements. It has a different approach to locating a compatible version of a module then pip does (pretty obvious at this point). pip errors when trying to install 2.1.0. easy_install does not.

Here is the URL for the wheel

https://files.pythonhosted.org/packages/e1/81/1dd79c5cd4320f2e904d7fbed7990d07c3b4e7a21efd2071be88dd5806f1/Sphinx-2.1.0-py2.py3-none-any.whl#sha256=2c5becc0fd6706dc0aeb4703f9f1f8a1d1eecacf02e9ac5943cbae48b11e5e42

1.8.5 is the last version made that is python 2.x compatible. My initial issue is solved.

There is still a bug so I am not going to close this issue.

@aodag
Copy link

aodag commented Jun 13, 2019

i thinks kdschlosser installed sphinx with easy_install, because that installed in egg directory.
easy_install can't install wheel format distribution, and easy_install may not support python_requires.

I tryed install sphinx on python 2.7 using pip19.1.1 and i got sphinx 1.8.5.
It's OK but wheel name has a little lie.

@kdschlosser
Copy link
Author

I didn't install using easy_install directly.

I had sphinx added to setup_requires in setuptools.setup()

My point is that if this is done and the version is not explicitly stated "sphinx==1.8.5" then 2.x gets installed on python 2.7.

There should not be a wheel named Sphinx-2.1.0-py2.py3-none-any.whl on pypi. the name explicitly states Sphinx 2.1.0 for Python 2, 3 (py2.py3) I believe setuptools/easy_install only looks at the name of the wheel to determine the packages compatibility.

pip does not use the wheel name in order to determine compatibility.

The setup I have done is a very real scenario and the underlying problem does need to be corrected. Not everyone uses pip. and obviously setuptools does not use it either when installing any requirements.

@tk0miya
Copy link
Member

tk0miya commented Jun 13, 2019

Thank you for reporting. I agree universal wheel (py2.py3 whl) is not good for Sphinx now. As a good timing, #6480 is posted now. So it will be applied to next stable release.

Note: I don't know why is Sphinx installed into your py2 env. We have version checking code in our setup.py...

sphinx/setup.py

Lines 13 to 15 in af50bfc

if sys.version_info < (3, 5):
print('ERROR: Sphinx requires at least Python 3.5 to run.')
sys.exit(1)

@tk0miya tk0miya added this to the 2.2.0 milestone Jun 13, 2019
@kdschlosser
Copy link
Author

ok good deal.

I do have a question relating to my use case. I wanted to build my documentation using either setuptools.setup or distutils.core.setup. I did not find anything already made to do this so I coded in the ability to do this. I did it in a manner that is not specific to my project and could be used by anyone, do you know if something like this already exists? would something like this be considered a good addition to Sphinx?.

if you wanted to take a look.
here is a line to the repo i just made for it.

https://github.com/kdschlosser/sphinx-distutils-extension

@aodag
Copy link

aodag commented Jun 14, 2019

we should use pyproject.toml(see PEP517,518) instead of setup_requires, or use extras_require.

@kdschlosser
Copy link
Author

@aodag

PEP517 and 518 are a good idea. but just like every other attempt at coming up with some kind of a build system requirements implementation (setup_requires, setup.cfg, requirements.txt) it falls short once again
.
pypa/pip#6144

for use with sphinx It might be OK to use. However I have not been able to determine if there is a way in the toml file to be able to programmatically alter what gets installed based on what command line argument is passed. I think that is the key thing that needs to be there. I do not think this is possible with the toml file because the command line parsing takes place once the setup.py file actually gets run. at that point a simple if "build_docs" in sys.argv statement can be used to create a list of setup requirements that would contain any sphinx extensions needed. But as a default sphinx would always get installed if building even if the documentation does not get generated. This is one of the negatives of using the toml file.

I personally think the easiest solution is for setuptools or distutils to add a function that would download a list of setup requirements before the call to setup gets made.

@kdschlosser
Copy link
Author

the author can duplicate the code from setuptools.command.easy_install to be able to add this ability. But it is quite a bit of code.

The funny thing is the mechanics are already made they are just being used in the wrong manner. and there is no way to be able to use the code before the call to setup ebcause it is build into a command class and not module level functions.

The people that are trying to sort out the requirements issue with pip, setuptools and distutils are over thinking how to solve the problem. sometimes you have to think simple to get the best solution. and a function to do the installs is about as simple as it gets.

@tk0miya
Copy link
Member

tk0miya commented Jun 14, 2019

I'm not good at install-toolkit for pythons (ex. setuptools, distutils, etc.). So I can't comment to you well.

would something like this be considered a good addition to Sphinx?.

Now, we don't have enough time to maintain sphinx-core. So I'm afraid that adding new feature makes Sphinx not maintained. It seems your sphinx-distutils-extension will be able to release as external package of Sphinx. So it would be better to ship it as standalone.

@kdschlosser
Copy link
Author

@tk0miya

I'm not good at install-toolkit for pythons (ex. setuptools, distutils, etc.)

I am getting better at it. It is a very complicated "mess" is what it is.

Now, we don't have enough time to maintain sphinx-core.

I can fully understand where you are coming from.

So it would be better to ship it as standalone.

I am also thinking because of the nature of how setuptools and distutils installs requirements it is best to have a smaller package like what I have created. A user could do a copy and paste of the code. It has a pretty small footprint. and that would make it easier to do It's only 2 classes.

@tk0miya
Copy link
Member

tk0miya commented Jun 15, 2019

Now #6480 is merged. So py2.py3 wheel will not be out since next release.
Thank you for reporting.

@tk0miya tk0miya closed this as completed Jun 15, 2019
tk0miya pushed a commit that referenced this issue Jun 19, 2019
Sphinx is Python-3-only and therefore is not a universal wheel. It
should still distribute a 'py3' wheel, just not a universal one.

From https://wheel.readthedocs.io/en/stable/user_guide.html

> If your project contains no C extensions and is expected to work on
> both Python 2 and 3, you will want to tell wheel to produce universal
> wheels by adding this to your setup.cfg file: …

As Sphinx doesn't work on Python 2, it should not be universal.

Refs #6470
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants