You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, our launch buttons are configured at the documentation-level. The GitHub repository etc are defined in conf.py and then used in each page.
However, there are some cases where users might want to specify per-page Binder configuration. For example, if a book has notebooks that require many different packages / languages / etc, the author might prefer to define a Binder environment for each in a different branch (or, multiple repositories), and then create different Binder links on each. (cc @acocac)
Proposal
We could make it possible to define page-level over-rides for launch buttons. For example, here might be two page-level over-rides, and each would over-ride the corresponding fields in the docs-level launch: configuration.
launch:
repository_url: https://github.com/foo/barbranch: bar
It might be tricky to get the UX right on this, because people probably won't want to duplicate their content, only the environment needed to run that content. So I think this might also depend on:
choldgraf
changed the title
Allow page-level over-riding of launch button functionality
Page-level over-riding of launch button functionality
Jul 13, 2022
Context
Currently, our launch buttons are configured at the documentation-level. The GitHub repository etc are defined in
conf.py
and then used in each page.However, there are some cases where users might want to specify per-page Binder configuration. For example, if a book has notebooks that require many different packages / languages / etc, the author might prefer to define a Binder environment for each in a different branch (or, multiple repositories), and then create different Binder links on each. (cc @acocac)
Proposal
We could make it possible to define page-level over-rides for launch buttons. For example, here might be two page-level over-rides, and each would over-ride the corresponding fields in the docs-level
launch:
configuration.and on another page:
It might be tricky to get the UX right on this, because people probably won't want to duplicate their content, only the environment needed to run that content. So I think this might also depend on:
Tasks and updates
No response
The text was updated successfully, but these errors were encountered: