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

Don't support installation via Git #1085

Open
agjohnson opened this issue Mar 12, 2021 · 3 comments
Open

Don't support installation via Git #1085

agjohnson opened this issue Mar 12, 2021 · 3 comments
Labels
Accepted Accepted issue on our roadmap Needed: design decision A core team decision is required
Milestone

Comments

@agjohnson
Copy link
Collaborator

Currently, we don't officially support installation via Git, but projects that are attempting to install via Git were required to build assets, via our build_py override. See #1037 and the #1039 temporary fix for some background.

We hit a number of issues supporting installation from Git:

  • We have no control over packaging
  • Users get an inconsistent experience, as core team treats releases as canonical versions, not master branch
  • PR merge conflicts on every PR and PR change
  • Installation via Git is mostly historical, we should solve user issues with unreleased fixes using development releases.

#1039 temporarily reverted customization of the package build process. There was a source package issue also in #1014 that is unrelated to removing package build override in #1039.

Work

  • Create a warning about Git installation deprecation. Detect when building from source or when using a non-release version of the theme. Perhaps there is something we can do with package version here?
  • Document deprecation
    • Notes on deprecation change
    • How we recommend using the theme for given use cases:
      • Users installing as a submodule to override SASS or for some unknown reason
        • Maintain your own fork against a Git tag, not master
      • Users installing via Git directly to get latest branch
        • Use RC packages instead
  • Release plan for deprecation

Design decisions

  • How to technically detect a direct installation at Sphinx build time?
  • What additional use cases are we concerned about?
  • How do we release backwards incompatible changes?
    • Initial change to announce deprecation
    • Final deprecation. Do we lump this in with Bootstrap changes?
@agjohnson agjohnson added Needed: design decision A core team decision is required Accepted Accepted issue on our roadmap labels Mar 12, 2021
@Blendify
Copy link
Member

or when using a non-release version of the theme.

This is possible with

https://github.com/readthedocs/sphinx_rtd_theme/pull/813/files

@agjohnson agjohnson added this to the 1.0 milestone Mar 17, 2021
@Blendify
Copy link
Member

Blendify commented Apr 2, 2021

I think for 1.0 we want to only deprecate, we can fully remove built assets in 2.0.

Is #813 good enough as a warning to users?

@agjohnson
Copy link
Collaborator Author

I think for 1.0 we want to only deprecate, we can fully remove built assets in 2.0.

Yeah, agreed. I added 1.0 here to get the deprecation warning added, but we can address that starting with #813

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Accepted Accepted issue on our roadmap Needed: design decision A core team decision is required
Projects
None yet
Development

No branches or pull requests

2 participants