https://github.com/quansight/qpub
deathbeds generalized automation framework
https://github.com/quansight/qpub
Last synced: about 1 year ago
JSON representation
deathbeds generalized automation framework
- Host: GitHub
- URL: https://github.com/quansight/qpub
- Owner: Quansight
- License: mit
- Created: 2020-11-12T22:24:23.000Z (over 5 years ago)
- Default Branch: main
- Last Pushed: 2021-02-03T21:36:49.000Z (over 5 years ago)
- Last Synced: 2025-05-08T20:01:44.722Z (about 1 year ago)
- Language: Python
- Size: 480 KB
- Stars: 4
- Watchers: 3
- Forks: 2
- Open Issues: 6
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# qpub - q(uick) publishing of python projects
`qpub` is an opinioned collection of conventional tasks for distributing python packages, tests, and documentation. `qpub` is a consistent CLI for publishing different forms of content in different environments (e.g. local develop/install, Github Actions testing, publishing to Github Pages, deploying Binders). It encodes different opinions for building, installing, testing, and documenting applications. Tool churn is real challenge for open source python development. `qpub` tries to aggregate best present and future practices for publishing different code artifacts.
`qpub` is good for small projects where content is :crown:. For existing projects, `qpub` may be a good test for transitioning old build chains to modern python conventions and for unifying testing and build frameworks across projects.
## What does `qpub` do?
`qpub` infers environment conditions using system variables and files in a git repo. From these partial initial conditions, `qpub` expands configuration files to aid in producing different forms of content. Content can include Python, RST, Markdown, or Jupyter Notebooks.
some features of `qpub` are:
blog infer the nikola blog documentation configuration.
build build the python project.
conda install conda requirements
config infer the jupyter_book documentation configuration.
develop install the project in development mode.
environment_yaml infer the project dependencies and write them to an environment.yaml
install install the packages into the sys.packages
jupyter_book build the documentation with jupyter-book
jupytext attach jupytext to the project to render python files.
lint lint and format the project with pre-commit
mkdocs build the documentation with mkdocs
mkdocs_yml infer the mkdocs documentation configuration.
nikola build the documentation with nikola
pip install pip requirements
precommit configure .pre-commit-config.yml for linting and formatting
pyproject infer the pyproject.toml configuration for the project
requirements_txt infer the project dependencies and write them to a requirements.txt
setup_cfg infer the declarative setup.cfg configuration for the project
sphinx build the documentation with sphinx
test test the project with pytest
toc infer the table of contents for the jupyter_book documentation.
uml generate a uml diagram for the project with pyreverse
### extra configuration
`qpub` will merge and append to existing configurations in smart ways. Extra configuration can be provided to any tool by seeding the correct configuration file with partial information.
## requirements
`qpub` requires a git repository with content.
# development
the `nox` file encodes common development tasks.
https://mozillascience.github.io/working-open-workshop/contributing/
https://gist.github.com/bollwyvl/f6aac8d4e68e5594fad2ae7a3cacc74b
https://gist.github.com/tonyfast/f74eb42f2a998d8e428a752ceb0cb1d1
should we pre install a bunch of different pytest opinions?
[github actions]: #
`
# qpub - q(uick) publishing of python projects
`qpub` is an opinioned collection of conventional tasks for distributing python packages, tests, and documentation. `qpub` is a consistent CLI for publishing different forms of content in different environments (eg. local develop/install, github actions testing, publishing to github pages, deploying binders). it encodes different opinions for building, installing, testing, and documenting applications. tool churn is real challenge for open source python development. `qpub` tries to aggregate best present and future practices for publishing different code artifacts.
`qpub` is good for small project where content is :crown:. for older projects, `qpub` may be a good test for transitioning old build chains to modern python conventions.
## what does `qpub` do?
`qpub` infers environment conditions using system variables and files in a git repo. from these partial initial conditions `qpub` expands configuration files for different publishing to aid produces different forms of content. content can include python, rst, markdown, or notebooks.
the collected features of `qpub` are:
```bash
blog infer the nikola blog documentation configuration.
build build the python project.
conda install conda requirements
config infer the jupyter_book documentation configuration.
develop install the project in development mode.
environment_yaml infer the project dependencies and write them to an environment.yaml
install install the packages into the sys.packages
jupyter_book build the documentation with jupyter-book
jupytext attach jupytext to the project to render python files.
lint lint and format the project with pre-commit
mkdocs build the documentation with mkdocs
mkdocs_yml infer the mkdocs documentation configuration.
nikola build the documentation with nikola
pip install pip requirements
precommit configure .pre-commit-config.yml for linting and formatting
pyproject infer the pyproject.toml configuration for the project
requirements_txt infer the project dependencies and write them to a requirements.txt
setup_cfg infer the declarative setup.cfg configuration for the project
sphinx build the documentation with sphinx
test test the project with pytest
toc infer the table of contents for the jupyter_book documentation.
uml generate a uml diagram for the project with pyreverse
```
### partial configuration
`qpub` will merge and append to existing configurations in smart ways. extra configuration can be provided to any tool by seeding the correct configuration file with partial information.
## requirements
`qpub` requires a git repository with content.
# development
the `nox` file encodes common development tasks.
https://mozillascience.github.io/working-open-workshop/contributing/
https://gist.github.com/bollwyvl/f6aac8d4e68e5594fad2ae7a3cacc74b
https://gist.github.com/tonyfast/f74eb42f2a998d8e428a752ceb0cb1d1
should we pre install a bunch of different pytest opinions?
[github actions]: #
`