From 53ce08fc4e5c867af17c916c9cc3be735c058e68 Mon Sep 17 00:00:00 2001 From: Richard Iannone Date: Tue, 3 Dec 2024 11:21:31 -0500 Subject: [PATCH 01/14] Create Contributing page and add to top nav --- docs/_quarto.yml | 2 ++ docs/contributing/index.qmd | 30 ++++++++++++++++++++++++++++++ 2 files changed, 32 insertions(+) create mode 100644 docs/contributing/index.qmd diff --git a/docs/_quarto.yml b/docs/_quarto.yml index 91a662fba..3c57c5a47 100644 --- a/docs/_quarto.yml +++ b/docs/_quarto.yml @@ -15,6 +15,8 @@ website: file: examples/index.qmd - href: reference/index.qmd text: Reference + - href: contributing/index.qmd + text: Contributing - href: blog/index.qmd text: Blog right: diff --git a/docs/contributing/index.qmd b/docs/contributing/index.qmd new file mode 100644 index 000000000..f935ea41c --- /dev/null +++ b/docs/contributing/index.qmd @@ -0,0 +1,30 @@ +--- +title: Contributing +format: html +--- + +# Information and Guidelines for Contributing to **great_tables** + +There are many ways to contribute to the ongoing development of the **great_tables** package. Some contributions can be rather easy to do (e.g., fixing typos, improving documentation, filing issues for feature requests or problems, etc.) whereas other contributions can require more time and patience (like answering questions and submitting pull requests with code changes). Just know that that help provided in any capacity is very much appreciated. :) + +## Filing Issues + +If you believe you found a bug, minimal reproducible example (MRE) for your posting to the [**great_tables** issue tracker](https://github.com/posit-dev/great-tables/issues). Try not to include anything unnecessary, just the minimal amount of code that constitutes the reproducible bug. We will try to verify the bug by running the code in the MRE provided. The quality of the MRE will reduce the amount of back-and-forth communication in trying to understand how to execute the code on our systems. + +## Answering questions + +A great way to help is by simply answering questions. It's amazing how a little conversation could lead to better insights on a problem. Don't quite know the answer? That's okay too. We're all in this together. + +Where might you answer user questions? Some of the forums for Q&A on **great_tables** include the _Issues_ and _Discussion_ pages in the repo. Good etiquette is key during these interactions: be a good person to all who ask questions. + +### Making Pull Requests + +Should you consider making a pull request (PR), please file an issue first and explain the problem in some detail. If the PR is an enhancement, detail how the change would make things better for package users. Bugfix PRs also require some explanation about the bug and how the proposed fix will remove that bug. A great way to illustrate the bug is to include an MRE. While all this upfront work prior to preparing a PR can be time-consuming it opens a line of communication with the package authors and the community, perhaps leading to a better enhancement or more effective fixes! + +Once there is consensus that a PR based on the issue would be helpful, adhering to the following process will make things proceed more quickly: + +- Create a separate Git branch for each PR. +- Look at the build status badges before and after making changes; these badges are available in the package [README](https://github.com/posit-dev/great-tables). +- The **great_tables** package follows the [Style Guide for Python Code](https://peps.python.org/pep-0008/) so please adopt those guidelines in your submitted code as best as possible. +- Comment your code, particularly in those hard-to-understand areas. +- We use **pytest** for code coverage; those contributions with test cases included are helpful and easier to accept. From 5f893fb70ad2a0bb26ba39e6b509829594b5114c Mon Sep 17 00:00:00 2001 From: Richard Iannone Date: Tue, 3 Dec 2024 12:20:46 -0500 Subject: [PATCH 02/14] Improve title presentation for Contributing on site --- docs/contributing/index.qmd | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/docs/contributing/index.qmd b/docs/contributing/index.qmd index f935ea41c..ae4cebdac 100644 --- a/docs/contributing/index.qmd +++ b/docs/contributing/index.qmd @@ -1,11 +1,9 @@ --- -title: Contributing +title: Information and Guidelines for Contributing to **great_tables** format: html --- -# Information and Guidelines for Contributing to **great_tables** - -There are many ways to contribute to the ongoing development of the **great_tables** package. Some contributions can be rather easy to do (e.g., fixing typos, improving documentation, filing issues for feature requests or problems, etc.) whereas other contributions can require more time and patience (like answering questions and submitting pull requests with code changes). Just know that that help provided in any capacity is very much appreciated. :) +There are many ways to contribute to the ongoing development of the **Great Tables** package. Some contributions can be rather easy to do (e.g., fixing typos, improving documentation, filing issues for feature requests or problems, etc.) whereas other contributions can require more time and patience (like answering questions and submitting pull requests with code changes). Just know that that help provided in any capacity is very much appreciated. :) ## Filing Issues From 055ee991a57b7468d837f8e6993df2f9ed988012 Mon Sep 17 00:00:00 2001 From: Richard Iannone Date: Tue, 3 Dec 2024 12:21:20 -0500 Subject: [PATCH 03/14] Improve title presentation for Contributing on site --- docs/contributing/index.qmd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/contributing/index.qmd b/docs/contributing/index.qmd index ae4cebdac..04dce7bc4 100644 --- a/docs/contributing/index.qmd +++ b/docs/contributing/index.qmd @@ -1,5 +1,5 @@ --- -title: Information and Guidelines for Contributing to **great_tables** +title: Information and Guidelines for Contributing to **Great Tables** format: html --- From c6ff7402c792a039e74005de5b3814f55962b01e Mon Sep 17 00:00:00 2001 From: Richard Iannone Date: Tue, 3 Dec 2024 12:27:12 -0500 Subject: [PATCH 04/14] Add link to MRE guide on Stack Overflow --- .github/CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index a51d1bf7d..a02c30674 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -4,7 +4,7 @@ There are many ways to contribute to the ongoing development of the **great_tabl ## Filing Issues -If you believe you found a bug, minimal reproducible example (MRE) for your posting to the [**great_tables** issue tracker](https://github.com/posit-dev/great-tables/issues). Try not to include anything unnecessary, just the minimal amount of code that constitutes the reproducible bug. We will try to verify the bug by running the code in the MRE provided. The quality of the MRE will reduce the amount of back-and-forth communication in trying to understand how to execute the code on our systems. +If you believe you found a bug, minimal reproducible example (MRE) for your posting to the [**great_tables** issue tracker](https://github.com/posit-dev/great-tables/issues). Try not to include anything unnecessary, just the minimal amount of code that constitutes the reproducible bug. For useful guidelines on how to create an MRE, take a look at [this guide on Stack Overflow](https://stackoverflow.com/help/minimal-reproducible-example). We will try to verify the bug by running the code in the provided MRE. The quality of the MRE will reduce the amount of back-and-forth communication in trying to understand how to execute the code on our systems. ## Answering questions From 356fae18a6b98b315ac2049ec75f6c1ac8d8b3c1 Mon Sep 17 00:00:00 2001 From: Richard Iannone Date: Tue, 3 Dec 2024 12:37:25 -0500 Subject: [PATCH 05/14] Move CONTRIBUTING.md to top level --- .github/CONTRIBUTING.md => CONTRIBUTING.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename .github/CONTRIBUTING.md => CONTRIBUTING.md (100%) diff --git a/.github/CONTRIBUTING.md b/CONTRIBUTING.md similarity index 100% rename from .github/CONTRIBUTING.md rename to CONTRIBUTING.md From 399bab51abadc756e36c9026333868f4a991cca6 Mon Sep 17 00:00:00 2001 From: Richard Iannone Date: Tue, 3 Dec 2024 12:41:51 -0500 Subject: [PATCH 06/14] Link to the CONTRIBUTING.md file in README.md --- README.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/README.md b/README.md index b25564884..13a987368 100644 --- a/README.md +++ b/README.md @@ -98,6 +98,12 @@ If you encounter a bug, have usage questions, or want to share ideas to make thi Please note that the **Great Tables** project is released with a [contributor code of conduct](https://www.contributor-covenant.org/version/2/1/code_of_conduct/).
By participating in this project you agree to abide by its terms. +## Contributing to **Great Tables** + +There are many ways to contribute to the ongoing development of the **Great Tables** package. Some contributions can be simple (like fixing typos, improving documentation, filing issues for feature requests or problems, etc.) and others might take more time and care (like answering questions and submitting PRs with code changes). Just know that anything you can do to help would be very much appreciated! + +Please read over the [contributing guidelines](https://github.com/posit-dev/great-tables/blob/main/CONTRIBUTING.md) for information on how to get started. + ## 📄 License **Great Tables** is licensed under the MIT license. From 0c2d6ac86de75c6bd932b493ef0420c7eaa463cc Mon Sep 17 00:00:00 2001 From: Richard Iannone Date: Tue, 3 Dec 2024 13:14:07 -0500 Subject: [PATCH 07/14] Add information about setting up dev environment --- CONTRIBUTING.md | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a02c30674..65175b1b4 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -23,3 +23,26 @@ Once there is consensus that a PR based on the issue would be helpful, adhering - The **great_tables** package follows the [Style Guide for Python Code](https://peps.python.org/pep-0008/) so please adopt those guidelines in your submitted code as best as possible. - Comment your code, particularly in those hard-to-understand areas. - We use **pytest** for code coverage; those contributions with test cases included are helpful and easier to accept. + +### Setting Up Your Development Environment + +To set up your development environment, you can follow these steps: + +- Clone the posit-dev/great-tables repository +- Create a virtual environment for the folder +- Install the package in editable mode with `pip install -e .` from the root of the project folder +- Install the development dependencies with `pip install .[dev]` (have a look at the `pyproject.toml` file for the list of development dependencies) + +Our documentation use `quartodoc` which in turn requires a local install of the Quarto CLI. To install Quarto, go to to get the latest build for your platform. + +We also use `ruff` for linting and formatting (this is part of our development dependencies). If using VS Code as your editor, it may be useful to install the `Ruff` extension. This will make it so any commits will pass the `pre-commit` checks. + +### Building the Documentation Locally + +Building the documentation can be done with `make docs-build` from the root of the project folder. Locally building the documentation site is useful when you want to see how your changes will look during iteration. The site will be built in the `docs/_site` folder. + +### Running Tests + +The tests are located in the `tests` folder and we use `pytest` for running them. To run all of the tests, use `make test`. If you want to run a specific test file, you can use `pytest tests/test_file.py`. + +If you create new tests involving snapshots, please ensure that the resulting snapshots are relatively small. After adding snapshots, use `make test-update` (this runs `pytest --snapshot-update`). A subsequent use of `make test` should pass without any issues. From ef74d5f09c0e8157dc153e11661a53f374f39094 Mon Sep 17 00:00:00 2001 From: Richard Iannone Date: Tue, 3 Dec 2024 13:20:01 -0500 Subject: [PATCH 08/14] Add info about the [all] optional install --- CONTRIBUTING.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 65175b1b4..8aa265905 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -37,6 +37,8 @@ Our documentation use `quartodoc` which in turn requires a local install of the We also use `ruff` for linting and formatting (this is part of our development dependencies). If using VS Code as your editor, it may be useful to install the `Ruff` extension. This will make it so any commits will pass the `pre-commit` checks. +If you are planning to investigate or submit a PR concerning the generation of table images, you need to install additional dependencies (`selenium`and`Pillow`) and this can be done by using `pip install .[all]`. + ### Building the Documentation Locally Building the documentation can be done with `make docs-build` from the root of the project folder. Locally building the documentation site is useful when you want to see how your changes will look during iteration. The site will be built in the `docs/_site` folder. From fd1f984ab22d61d742e2636d1db5e80d94ecb05e Mon Sep 17 00:00:00 2001 From: Richard Iannone Date: Tue, 3 Dec 2024 13:23:26 -0500 Subject: [PATCH 09/14] Add note on running `pre-commit` at terminal --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8aa265905..54eed6aa8 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -35,7 +35,7 @@ To set up your development environment, you can follow these steps: Our documentation use `quartodoc` which in turn requires a local install of the Quarto CLI. To install Quarto, go to to get the latest build for your platform. -We also use `ruff` for linting and formatting (this is part of our development dependencies). If using VS Code as your editor, it may be useful to install the `Ruff` extension. This will make it so any commits will pass the `pre-commit` checks. +We also use `ruff` for linting and formatting (this is part of our development dependencies). If using VS Code as your editor, it may be useful to install the `Ruff` extension. This will make it so any commits will pass the `pre-commit` checks. You can verify that any changes pass all pre-commit checks by running `pre-commit run --all-files`. If you are planning to investigate or submit a PR concerning the generation of table images, you need to install additional dependencies (`selenium`and`Pillow`) and this can be done by using `pip install .[all]`. From 7a68de15e3d32984bcea1327b54d9d289b109ab4 Mon Sep 17 00:00:00 2001 From: Richard Iannone Date: Tue, 3 Dec 2024 13:29:11 -0500 Subject: [PATCH 10/14] Add statement on req for new tests --- CONTRIBUTING.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 54eed6aa8..22ca2f48f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -18,11 +18,11 @@ Should you consider making a pull request (PR), please file an issue first and e Once there is consensus that a PR based on the issue would be helpful, adhering to the following process will make things proceed more quickly: -- Create a separate Git branch for each PR. -- Look at the build status badges before and after making changes; these badges are available in the package [README](https://github.com/posit-dev/great-tables). -- The **great_tables** package follows the [Style Guide for Python Code](https://peps.python.org/pep-0008/) so please adopt those guidelines in your submitted code as best as possible. -- Comment your code, particularly in those hard-to-understand areas. -- We use **pytest** for code coverage; those contributions with test cases included are helpful and easier to accept. +- Create a separate Git branch for each PR +- Look at the build status badges before and after making changes; these badges are available in the package [README](https://github.com/posit-dev/great-tables) +- The **great_tables** package follows the [Style Guide for Python Code](https://peps.python.org/pep-0008/) so please adopt those guidelines in your submitted code as best as possible +- Comment your code, particularly in those hard-to-understand areas +- Add test cases that cover the changes made in the PR; having tests for any new codepaths will help guard against regressions ### Setting Up Your Development Environment From cafc7360e1fc729e70cc106faf006422a1e57dc2 Mon Sep 17 00:00:00 2001 From: Richard Iannone Date: Tue, 3 Dec 2024 13:30:22 -0500 Subject: [PATCH 11/14] Update CONTRIBUTING.md --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 22ca2f48f..f04c1a765 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -43,7 +43,7 @@ If you are planning to investigate or submit a PR concerning the generation of t Building the documentation can be done with `make docs-build` from the root of the project folder. Locally building the documentation site is useful when you want to see how your changes will look during iteration. The site will be built in the `docs/_site` folder. -### Running Tests +### Running Tests Locally The tests are located in the `tests` folder and we use `pytest` for running them. To run all of the tests, use `make test`. If you want to run a specific test file, you can use `pytest tests/test_file.py`. From ff2627794ea905f39752ee3c37c8402ef828ceda Mon Sep 17 00:00:00 2001 From: Richard Iannone Date: Tue, 3 Dec 2024 23:02:01 -0500 Subject: [PATCH 12/14] Move Contributing page to bottom of Get Started --- docs/_quarto.yml | 5 +++-- .../{contributing/index.qmd => get-started/contributing.qmd} | 0 2 files changed, 3 insertions(+), 2 deletions(-) rename docs/{contributing/index.qmd => get-started/contributing.qmd} (100%) diff --git a/docs/_quarto.yml b/docs/_quarto.yml index 3c57c5a47..f3018f91c 100644 --- a/docs/_quarto.yml +++ b/docs/_quarto.yml @@ -15,8 +15,6 @@ website: file: examples/index.qmd - href: reference/index.qmd text: Reference - - href: contributing/index.qmd - text: Contributing - href: blog/index.qmd text: Blog right: @@ -54,6 +52,9 @@ website: - get-started/column-selection.qmd - get-started/row-selection.qmd - get-started/loc-selection.qmd + - section: Extra + contents: + - get-started/contributing.qmd format: html: diff --git a/docs/contributing/index.qmd b/docs/get-started/contributing.qmd similarity index 100% rename from docs/contributing/index.qmd rename to docs/get-started/contributing.qmd From 8de759bcf9cbf16695b5ef628d665a9f551e21af Mon Sep 17 00:00:00 2001 From: Richard Iannone Date: Tue, 3 Dec 2024 23:18:29 -0500 Subject: [PATCH 13/14] Shorten title of Contributing Guidelines page --- docs/get-started/contributing.qmd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/get-started/contributing.qmd b/docs/get-started/contributing.qmd index 04dce7bc4..ab4093c91 100644 --- a/docs/get-started/contributing.qmd +++ b/docs/get-started/contributing.qmd @@ -1,5 +1,5 @@ --- -title: Information and Guidelines for Contributing to **Great Tables** +title: Contributing Guidelines format: html --- From 8d715b161ffa4f58e915b5f45035c32b81491457 Mon Sep 17 00:00:00 2001 From: Richard Iannone Date: Tue, 3 Dec 2024 23:32:25 -0500 Subject: [PATCH 14/14] Make minor text fixes; ensure two copies of guide --- CONTRIBUTING.md | 12 ++++----- docs/get-started/contributing.qmd | 43 ++++++++++++++++++++++++------- 2 files changed, 40 insertions(+), 15 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index f04c1a765..99e3a605a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,16 +1,16 @@ -# Information and Guidelines for Contributing to **great_tables** +# Contributing Guidelines -There are many ways to contribute to the ongoing development of the **great_tables** package. Some contributions can be rather easy to do (e.g., fixing typos, improving documentation, filing issues for feature requests or problems, etc.) whereas other contributions can require more time and patience (like answering questions and submitting pull requests with code changes). Just know that that help provided in any capacity is very much appreciated. :) +There are many ways to contribute to the ongoing development of the Great Tables package. Some contributions can be rather easy to do (e.g., fixing typos, improving documentation, filing issues for feature requests or problems, etc.) whereas other contributions can require more time and patience (like answering questions and submitting pull requests with code changes). Just know that that help provided in any capacity is very much appreciated. :) ## Filing Issues -If you believe you found a bug, minimal reproducible example (MRE) for your posting to the [**great_tables** issue tracker](https://github.com/posit-dev/great-tables/issues). Try not to include anything unnecessary, just the minimal amount of code that constitutes the reproducible bug. For useful guidelines on how to create an MRE, take a look at [this guide on Stack Overflow](https://stackoverflow.com/help/minimal-reproducible-example). We will try to verify the bug by running the code in the provided MRE. The quality of the MRE will reduce the amount of back-and-forth communication in trying to understand how to execute the code on our systems. +If you believe you found a bug, minimal reproducible example (MRE) for your posting to the [Great Tables issue tracker](https://github.com/posit-dev/great-tables/issues). Try not to include anything unnecessary, just the minimal amount of code that constitutes the reproducible bug. For useful guidelines on how to create an MRE, take a look at [this guide on Stack Overflow](https://stackoverflow.com/help/minimal-reproducible-example). We will try to verify the bug by running the code in the provided MRE. The quality of the MRE will reduce the amount of back-and-forth communication in trying to understand how to execute the code on our systems. ## Answering questions -A great way to help is by simply answering questions. It's amazing how a little conversation could lead to better insights on a problem. Don't quite know the answer? That's okay too. We're all in this together. +One way to help is by simply answering questions. It's amazing how a little conversation could lead to better insights on a problem. Don't quite know the answer? That's okay too. We're all in this together. -Where might you answer user questions? Some of the forums for Q&A on **great_tables** include the _Issues_ and _Discussion_ pages in the repo. Good etiquette is key during these interactions: be a good person to all who ask questions. +Where might you answer user questions? Some of the forums for Q&A on Great Tables include the _Issues_ and _Discussion_ pages in the repo. Good etiquette is key during these interactions: be a good person to all who ask questions. ### Making Pull Requests @@ -20,7 +20,7 @@ Once there is consensus that a PR based on the issue would be helpful, adhering - Create a separate Git branch for each PR - Look at the build status badges before and after making changes; these badges are available in the package [README](https://github.com/posit-dev/great-tables) -- The **great_tables** package follows the [Style Guide for Python Code](https://peps.python.org/pep-0008/) so please adopt those guidelines in your submitted code as best as possible +- The Great Tables package follows the [Style Guide for Python Code](https://peps.python.org/pep-0008/) so please adopt those guidelines in your submitted code as best as possible - Comment your code, particularly in those hard-to-understand areas - Add test cases that cover the changes made in the PR; having tests for any new codepaths will help guard against regressions diff --git a/docs/get-started/contributing.qmd b/docs/get-started/contributing.qmd index ab4093c91..2f385efc5 100644 --- a/docs/get-started/contributing.qmd +++ b/docs/get-started/contributing.qmd @@ -3,17 +3,17 @@ title: Contributing Guidelines format: html --- -There are many ways to contribute to the ongoing development of the **Great Tables** package. Some contributions can be rather easy to do (e.g., fixing typos, improving documentation, filing issues for feature requests or problems, etc.) whereas other contributions can require more time and patience (like answering questions and submitting pull requests with code changes). Just know that that help provided in any capacity is very much appreciated. :) +There are many ways to contribute to the ongoing development of the Great Tables package. Some contributions can be rather easy to do (e.g., fixing typos, improving documentation, filing issues for feature requests or problems, etc.) whereas other contributions can require more time and patience (like answering questions and submitting pull requests with code changes). Just know that that help provided in any capacity is very much appreciated. :) ## Filing Issues -If you believe you found a bug, minimal reproducible example (MRE) for your posting to the [**great_tables** issue tracker](https://github.com/posit-dev/great-tables/issues). Try not to include anything unnecessary, just the minimal amount of code that constitutes the reproducible bug. We will try to verify the bug by running the code in the MRE provided. The quality of the MRE will reduce the amount of back-and-forth communication in trying to understand how to execute the code on our systems. +If you believe you found a bug, minimal reproducible example (MRE) for your posting to the [Great Tables issue tracker](https://github.com/posit-dev/great-tables/issues). Try not to include anything unnecessary, just the minimal amount of code that constitutes the reproducible bug. For useful guidelines on how to create an MRE, take a look at [this guide on Stack Overflow](https://stackoverflow.com/help/minimal-reproducible-example). We will try to verify the bug by running the code in the provided MRE. The quality of the MRE will reduce the amount of back-and-forth communication in trying to understand how to execute the code on our systems. ## Answering questions -A great way to help is by simply answering questions. It's amazing how a little conversation could lead to better insights on a problem. Don't quite know the answer? That's okay too. We're all in this together. +One way to help is by simply answering questions. It's amazing how a little conversation could lead to better insights on a problem. Don't quite know the answer? That's okay too. We're all in this together. -Where might you answer user questions? Some of the forums for Q&A on **great_tables** include the _Issues_ and _Discussion_ pages in the repo. Good etiquette is key during these interactions: be a good person to all who ask questions. +Where might you answer user questions? Some of the forums for Q&A on Great Tables include the _Issues_ and _Discussion_ pages in the repo. Good etiquette is key during these interactions: be a good person to all who ask questions. ### Making Pull Requests @@ -21,8 +21,33 @@ Should you consider making a pull request (PR), please file an issue first and e Once there is consensus that a PR based on the issue would be helpful, adhering to the following process will make things proceed more quickly: -- Create a separate Git branch for each PR. -- Look at the build status badges before and after making changes; these badges are available in the package [README](https://github.com/posit-dev/great-tables). -- The **great_tables** package follows the [Style Guide for Python Code](https://peps.python.org/pep-0008/) so please adopt those guidelines in your submitted code as best as possible. -- Comment your code, particularly in those hard-to-understand areas. -- We use **pytest** for code coverage; those contributions with test cases included are helpful and easier to accept. +- Create a separate Git branch for each PR +- Look at the build status badges before and after making changes; these badges are available in the package [README](https://github.com/posit-dev/great-tables) +- The Great Tables package follows the [Style Guide for Python Code](https://peps.python.org/pep-0008/) so please adopt those guidelines in your submitted code as best as possible +- Comment your code, particularly in those hard-to-understand areas +- Add test cases that cover the changes made in the PR; having tests for any new codepaths will help guard against regressions + +### Setting Up Your Development Environment + +To set up your development environment, you can follow these steps: + +- Clone the posit-dev/great-tables repository +- Create a virtual environment for the folder +- Install the package in editable mode with `pip install -e .` from the root of the project folder +- Install the development dependencies with `pip install .[dev]` (have a look at the `pyproject.toml` file for the list of development dependencies) + +Our documentation use `quartodoc` which in turn requires a local install of the Quarto CLI. To install Quarto, go to to get the latest build for your platform. + +We also use `ruff` for linting and formatting (this is part of our development dependencies). If using VS Code as your editor, it may be useful to install the `Ruff` extension. This will make it so any commits will pass the `pre-commit` checks. You can verify that any changes pass all pre-commit checks by running `pre-commit run --all-files`. + +If you are planning to investigate or submit a PR concerning the generation of table images, you need to install additional dependencies (`selenium`and`Pillow`) and this can be done by using `pip install .[all]`. + +### Building the Documentation Locally + +Building the documentation can be done with `make docs-build` from the root of the project folder. Locally building the documentation site is useful when you want to see how your changes will look during iteration. The site will be built in the `docs/_site` folder. + +### Running Tests Locally + +The tests are located in the `tests` folder and we use `pytest` for running them. To run all of the tests, use `make test`. If you want to run a specific test file, you can use `pytest tests/test_file.py`. + +If you create new tests involving snapshots, please ensure that the resulting snapshots are relatively small. After adding snapshots, use `make test-update` (this runs `pytest --snapshot-update`). A subsequent use of `make test` should pass without any issues.