Sphinx 1.7 breaks travis-sphinx

[kohr-h]

Sphinx 1.7 removes the build_main function:

File "/home/travis/miniconda/envs/testenv/lib/python3.6/site-packages/travis_sphinx/build.py", line 39, in build
    if sphinx.build_main(args + [source, outdir]):
AttributeError: module 'sphinx' has no attribute 'build_main'

This is with the newest version of travis-sphinx but I suspect earlier ones are also affected. I'm not sure how to solve it, but a quick fix would be a dependency sphinx<1.7 in the setup.py.

[tyralla]

Function build_main is now placed in subpackage build. So it seems easy to fix this problem (albeit I don't know what else is new in sphinx 1.7). However, I am not sure if the travis-sphinx repository is still maintained...

[kohr-h]

Function build_main is now placed in subpackage build. So it seems easy to fix this problem (albeit I don't know what else is new in sphinx 1.7).

Seems easy enough.

However, I am not sure if the travis-sphinx repository is still maintained...

Huh? What makes you think it isn't?

[Syntaf]

As mentioned in @kohr-h's PR, i'd like to find a way to support > 1.7 without breaking pre 1.7, even if it may create difficulties. There are a number of existing repos likely using pre 1.7 sphinx and counting on travis sphinx to not suddenly break.

[Syntaf]

sphinx-doc/sphinx#4623

[kohr-h]

"build_main is not a public interface", is that something to worry about?

[Syntaf]

@kohr-h Since that only concerns the new build_main , I think we should be fine as it is since we're using the new approach > 1.7

[kohr-h]

It's fine for now, yes, but my question was more as to whether or not you consider it problematic that travis-sphinx uses a non-public interface that may change in the future between Sphinx versions without notice or deprecation period (as it did). Not that I know of any alternative, though.

[Syntaf]

Ah I see now, I thought that comment was only saying the previous build_main was not a public interface. Although it's not public, I think it's OK moving forward with the > 1.7 fix as is. If in the near future they decide to remove build_main we'll just need to find a more unique solution

[Syntaf]

New version released today with the fixes made by @kohr-h , thanks for your help! I'll be closing this ticket as I believe the problem has now been fixed.

[kohr-h]

Cool!

[iltommi]

thanks!

[iltommi]

I was able to use travis sphinx and now I get again some error:
https://travis-ci.org/SmileiPIC/Smilei/builds/346835732#L613

Traceback (most recent call last):
  File "/home/travis/.local/bin/travis-sphinx", line 11, in <module>
    sys.exit(main())
  File "/home/travis/.local/lib/python2.7/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/home/travis/.local/lib/python2.7/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/home/travis/.local/lib/python2.7/site-packages/click/core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/travis/.local/lib/python2.7/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/travis/.local/lib/python2.7/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/home/travis/.local/lib/python2.7/site-packages/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/home/travis/.local/lib/python2.7/site-packages/travis_sphinx/build.py", line 50, in build
    if sphinx_build(args + [source, outdir]):
  File "/home/travis/.local/lib/python2.7/site-packages/sphinx/__init__.py", line 81, in build_main
    return build.build_main(argv[1:])  # skip first argument to adjust arguments (refs: #4615)
NameError: global name 'build' is not defined

[Syntaf]

Looks like we need to add a bit more robust error checking, and defer to the older version upon catching anything. Thanks for report.

Edit: do you know what sphinx version the build is using?

[iltommi]

Sphinx-1.7.1-py2.py3-none-any.whl installed via pip : https://travis-ci.org/SmileiPIC/Smilei/jobs/346835733#L548

[kohr-h]

See PR, Sphinx changed their subpackages to be lazily loaded. I wonder how many packages they break by that...

[iltommi]

Has this commit been pushed via pip?
Otherwise how can I get it on travis?

I'm still having the same isuees : https://travis-ci.org/SmileiPIC/Smilei/jobs/349720388#L625

0.15s$ travis-sphinx build -n -s doc/Sphinx
Traceback (most recent call last):
  File "/home/travis/.local/bin/travis-sphinx", line 11, in <module>
    sys.exit(main())
  File "/home/travis/.local/lib/python2.7/site-packages/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/home/travis/.local/lib/python2.7/site-packages/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/home/travis/.local/lib/python2.7/site-packages/click/core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/travis/.local/lib/python2.7/site-packages/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/travis/.local/lib/python2.7/site-packages/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/home/travis/.local/lib/python2.7/site-packages/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/home/travis/.local/lib/python2.7/site-packages/travis_sphinx/build.py", line 50, in build
    if sphinx_build(args + [source, outdir]):
  File "/home/travis/.local/lib/python2.7/site-packages/sphinx/__init__.py", line 81, in build_main
    return build.build_main(argv[1:])  # skip first argument to adjust arguments (refs: #4615)
NameError: global name 'build' is not defined

[lmignon]

@Syntaf @kohr-h Why do you need to support multiple versions of sphinx? Could we stick with Sphynx => 1.7. (We can enforce the minimal version of sphinx into setup.py) IMO The last changes looks like hacks.

[kohr-h]

Why do you need to support multiple versions of sphinx?

Because users use multiple versions of sphinx. What if some other package in a user's environment needs sphinx<1.7? Then they can't install that and travis-sphinx at the same time, and our setup.py effectively breaks their environment for a tiny reason.

IMO The last changes looks like hacks.

It's not a hack, it's just adaption to a shifting target that travis-sphinx depends upon. Of course, if nobody would ever break a public API, the world would be a better place (maybe), but sometimes you just have to suck it up and deal with those things.
To take this as a reason to stop supporting older versions of sphinx would be a huge overreach IMO.

[kohr-h]

Has this commit been pushed via pip?
Otherwise how can I get it on travis?

I don't think there's a pip package yet that has the fix. In the meanwhile you can enforce sphinx<1.7.1 to not run into this issue.

[lmignon]

@kohr-h

Because users use multiple versions of sphinx.

IMO the proper way to fix this problem without hacking the code is to create 2 new releases.
The first one will enforce sphinx <1.7.1 for users relying specifically on a specific sphinx version. (2.1.1)
Once released we could drop the support of sphinx 1.7.1 and enforce sphinx => 1.7.1 (2.2.0)

[kohr-h]

Maybe, in some sense of "proper", this would be the way of doing it. The result will be two release lines that differ in roughly 4 lines of code, but require double the work in the release process. Then the next Sphinx API change (or of any other dependency, for that matter) comes about, and the same thing has to be done again. It's cleaner, yes, but at what price?