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

Theme fix - use style sources from theme instead from built-in #91

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

thiersa
Copy link

@thiersa thiersa commented Nov 6, 2023

In the main branch the code that compiles SCCS source files into CSS always uses the SCCS sources from the builtin theme ('simplepdf_theme').

This fix gets the SCCS sources from the theme package itself.

Copy link
Member

@danwos danwos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix, makes sense 👍

I think there is only one bug in it...

And would it be okay for you to add 1-2 lines to the docs of
simplepdf-theme, that SCSS sources get compiled from static/styles/sources.


if self.app.config.simplepdf_theme is not None:
try:
theme_folder = os.path.dirname(import_module(self.app.config.html_theme).__file__)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be simplepdf_theme instead of html_theme?

@j123b567
Copy link
Contributor

j123b567 commented Nov 9, 2023

It is something that I recently needed but after some thought, this particular implementation makes a very strong assumption that all user themes will always have static/styles/sources directory with scss which may not be true.

The user can use a custom theme and for example add app.add_css_file('custom.css') to override just some aspects of the original style of the theme. This use-case will break completely with this PR.

@danwos
Copy link
Member

danwos commented Nov 13, 2023

@j123b567, you are right, the folder structure of static/styles/sources is given for the theme.
But for me all the other scenarios are still possible, using html_css or app.add_css_file().

But for sure, the PR needs some love to document the "forced" theme structure in the docs.

@j123b567
Copy link
Contributor

From this point, in all custom themes, you will be forced to have at least empty static/styles/sources/main.scss and then you can use app.add_css_file()

IMHO the main problem is that the theme should be decoupled from the builder in the first place and not make it worse.

It should be possible to connect to the event "builder-inited", "env-updated", or other events and compile the theme in the callback and not in the builder

Did you try this possibility in the past and it was a dead end?

@thiersa
Copy link
Author

thiersa commented Nov 13, 2023 via email

@j123b567
Copy link
Contributor

@thiersa ou, I just implemented it also in #94

@danwos
Copy link
Member

danwos commented Nov 13, 2023

Just reviewed #94 and it looks good to me.
If nobody has any concerns with #94, I will merge it soon.

@danwos
Copy link
Member

danwos commented Nov 13, 2023

Hehe, now we have two similar solutions #91 and #94 :)
Good work for both of you, any chance you two build a consense which one to take :)
For sure both of you can be added to the AUTHORS, if you like.

Copy link
Member

@danwos danwos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR 👍
Looks good, only one minor (very subjective) finding.

setup.py Outdated
@@ -11,7 +11,7 @@

setup(
name='sphinx-simplepdf',
version='1.6.0',
version='1.6.2a1',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like to raise versions in separate PR, so may I ask you to remove this?

@thiersa
Copy link
Author

thiersa commented Nov 13, 2023 via email

@thiersa
Copy link
Author

thiersa commented Nov 13, 2023 via email

@j123b567
Copy link
Contributor

I didn't try to understand deeply get_config_var and get_theme_var so this implementation is much simpler and should be preferred.

I just don't like changing version information inside PRs like this so __version__ inside theme and inside extension should be changed only by maintainers. Also, shouldn't the version of the theme match the version of the extension?


__version__ = '0.1.0'

__version__ = '0.3.0'
Copy link
Member

@danwos danwos Nov 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here also: I would like to stay with 0.1.0 and raise it with an additional PR.

@j123b567
Copy link
Contributor

There is another issue - simplepdf_vars and simplepdf_theme_options are used only in the theme so if the registration of these variables (app.add_config_value) should be also moved to the theme setup.

This is not a problem of the sphinx-simplepdf itself but of any derived theme. E.g. if somebody copies or derive the theme, it is still not self-contained. So other targets than simplepdf will fail because of missing app.config.simplepdf_vars. This move will just pronounce the fact, that anybody copying the theme should also handle these config variables.

This PR is all about using a custom theme so we should probably handle this also.

@thiersa
Copy link
Author

thiersa commented Nov 16, 2023

Just changed back the theme version to 0.1.0 as requested.
Another thing, reflecting on Jan's comment about the dependency of the simplepdf_theme_options.
This setting is only used to override the settings of html_theme_options. Most (all?) of the templating machinery on the backend is referring to app.config.html_theme_options.
So why not just use this:

  • the simplepdf builder replaces the html_theme_options by the simplepdf_theme_options (which is already the case).
  • the themes (both built-in and any derived theme) use app.config.html_theme_options instead of app.config.simplepdf_theme_options
  • IMHO, the information in simplepdf_vars can just as well be contained in simplepdf_theme_option. After all it is information to tweak the theme.

This way themes can be created just like any other html theme, but they do not interfere with a theme that is used for html generation. With the same conf.py you can generate html and pdf.
And you can still use the elegant mechanism with sass.compile to parameterize the theme.

Your thoughts?

@danwos
Copy link
Member

danwos commented Nov 17, 2023

Generally, it is a good idea to use html_theme_options internally and overwrite it initially with simplepdf_theme_options.
However, I can roughly remember trying this at the beginning of this project and it failed somehow.
Maybe because of the caching mechanisms of Sphinx or the way incremental build works. But I'm not 100% sure.
May be worth testing it again.

Regarding simplepdf_vars, I would keep it as it is and not integrate it into simplepdf_theme_options.
Mostly because I don't see any benefit and it would be a breaking change.

@@ -14,10 +16,33 @@ def get_html_theme_path():
return cur_dir


def create_custom_css(app):

def get_config_var(name, default):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we keep the doc_string of the original function here?
I know the code is understandable without it, but it also explains the use case and therefore why it is needed.

# See http://www.sphinx-doc.org/en/stable/theming.html#distribute-your-theme-as-a-python-package
def setup(app):
app.add_html_theme('simplepdf_theme', path.abspath(path.dirname(__file__)))
# app.add_css_file('styles/main.css')
app.connect('builder-inited', create_custom_css)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think with this line we call create_custom_css every time, so for each builder including html.

We should add a check inside create_custom_css if the current builder is simplepdf.

@danwos
Copy link
Member

danwos commented Nov 17, 2023

There is another issue - simplepdf_vars and simplepdf_theme_options are used only in the theme so if the registration of these variables (app.add_config_value) should be also moved to the theme setup.

I like to have all sphinx registration options in one place.
Easier to maintain and maybe in the future the builder itself needs to have access to it as well.

Also I think a simplepdf theme is always used together with the simplepdf builder/extension.
So if we move it to the theme, there is then also a chance that users are missing it.

I would solve this problem with better documentation.
Maybe a short chapter to create a custom theme...

@j123b567
Copy link
Contributor

@danwos sounds good so no need to do anything special now.

@thiersa
Copy link
Author

thiersa commented Nov 23, 2023

Just added back the docstrings in the two config functions in the theme.
Good point to keep simplepdf_vars to prevent a breaking change.
As a theme developer you still have the choice to use it or not.

As far as overwriting the html_theme_options is concerned; I haven't experienced any issues, none of mine regressions failed.
Maybe @danwos can recall a failing edge-case.

@lino-alves
Copy link

Is there anything preventing this merge and the release of new packages?

We have a custom theme in our environment and these changes here in theory would solve our problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants