GRASS-Wiki - User contributions [en]

GRASS GSoC 2026 Support writing tests with pytest

2026-05-05T03:28:32Z

Gulshan: mentor name change

{| class="wikitable"
| '''Student Name''' || Gulshan Kumar
|-
| '''Organization''' || [https://numfocus.org/ NumFOCUS]
|-
| '''Mentor Name''' || Vaclav Petras, Corey White
|-
| '''GitHub Fork''' || [https://github.com/gulshan-123/grass View Repo]
|-
| '''LinkedIn Profile''' || [https://www.linkedin.com/in/gul-shan123 View LinkedIn]
|}

= Abstract =
The current test framework in GRASS, gunittest, was designed before GitHub era. Based on Python unittest, it has several distinct types of assertion methods and requires tests to be executed from within a GRASS shell session. This has steep learning curve and is far from modern testing methods which uses Pytest.

This project aims to modify the GRASS test by shifting the testing framework to pytest. Pytest uses simple and plain assert statements, fixtures, and is more readable. The project will involve designing a new API for several grass related assertions, implementing fixtures to handle GRASS sessions and temporary mapsets outside of the GRASS shell, integrating sample datasets, and iterative refactoring (utilizing tools like Bowler) to migrate existing tests. Thus, this will result in a more Pythonic, accessible, and maintainable testing environment for GRASS contributors.

= Project Scope =
# API Design: Designing how GRASS specific assertions (like rasterExists) will look in pytest. We will draw inspiration from NumPy/GDAL own migration history.
# Session & Mapset Fixtures: Designing pytest fixtures to handle GRASS session setup and teardown. This also include running pytest outside of a GRASS session.
# Isolation: Tests must be isolated to ensure there is no side effects between them. We will decide on per file/per function isolation.
# Sample Dataset Integration: Addressing the dependency on the NC SPM sample dataset from grass.gunittest to the pytest framework.
# Iterative Refactoring Strategy: Defining the location for the new tests (tests or testsuite directories) and utilizing AST-based refactoring tools like Bowler (combined with AI agents) to automate the migration of existing tests.
# Contributor Documentation: Creating a user friendly testing guide for future contributors to encourage rapid adoption of the new pytest framework.

= Timeline =
{| class="wikitable"
!Period !! Timeline !! Tasks !! Status
|-
| Community Bonding Period
||
May 1 - May 24, 2026
||
# Finalize the API design for the new assertion functions alongside mentors.
# Research NumPy and GDAL transition to pytest for more insights.
# Engage with the community to establish conventions for the new tests structure.
||
|-
| rowspan="13" | Official Coding Period
|-
| '''Week 1''' (May 25 - May 31) ||
# Implement fixtures to allow pytest execution outside the GRASS shell in conftest.py.
# Fix grass.script.setup.init behavior.
||
|-
| '''Week 2''' (June 1 - June 7) ||
# Implement function/module scoped fixtures for temporary mapset creation and teardown. Ensure environment isolation.
||
|-
| '''Week 3''' (June 8 - June 14) ||
# Begin translating basic gunittest assertions to pytest equivalents.
||
|-
| '''Week 4''' (June 15 - June 21) ||
# Implement complex geospatial comparison functions (e.g., vector/raster fitting).
||
|-
| '''Week 5''' (June 22 - June 28) ||
# Work on integrating the NC SPM sample dataset into the new pytest architecture.
||
|-
| '''Week 6''' (June 29 - July 5) ||
# Finalize dataset integration.
# Write unit tests for the new pytest fixtures and utilities to ensure framework stability.
||
|-
| style="background:#ffdead;" | '''Midterm Evaluation''' (July 6 - July 10) ||
# Submit MidTerm evaluation.
||
|-
| '''Week 7''' (July 6 - July 12) ||
# Develop automation scripts using Bowler (and AI assistance) for iterative refactoring of existing test suites.
||
|-
| '''Week 8''' (July 13 - July 19) ||
# Begin migrating test files from unittest to pytest.
# Decide on unittest class structures vs. pure functions based on mentor feedback.
||
|-
| '''Week 9''' (July 20 - July 26) ||
# Continue iterative migration, focusing on tests that failed or interacted poorly with grass --exec.
||
|-
| '''Week 10''' (July 27 - August 2) ||
# Draft the User Guide for contributors on how to write tests using the new pytest framework.
||
|-
| '''Week 11''' (August 3 - August 9) ||
# Address edge cases, fix failing tests resulting from the migration, and ensure CI pipelines are green.
||
|-
| '''Week 12''' (August 10 - August 16) ||
# Buffer week. Code cleanup, finalizing PRs, and reviewing documentation.
||
|-
| Final Week
| August 17 - August 24
|
# Submit Report, Project, Blog and Documentation
|
|}

= Reports =
== Community Bonding Period ==

= Log of Pull Requests =
{| class="wikitable"
! PR !! PR Title
|-
| [https://github.com/OSGeo/grass/pull/7071 #7071] || g.parser: Missing support G_OPT_F FORMAT in python %option
|-
| [https://github.com/OSGeo/grass/pull/7051 #7051] || t.vect.list: Added support for JSON, YAML and CSV
|-
| [https://github.com/OSGeo/grass/pull/7004 #7004] || grass.jupyter: use json output format in timeseriesmap
|-
| [https://github.com/OSGeo/grass/pull/6971 #6971] || db.columns: added format list and format=csV
|-
| [https://github.com/OSGeo/grass/pull/6933 #6933] || db.columns: added support for -e to print more column information
|-
| [https://github.com/OSGeo/grass/pull/6867 #6867] || v.info: Add format csv with c flag and sync with v.db.connect
|-
| [https://github.com/OSGeo/grass/pull/6823 #6823] || v.info: Sync -c flag with format=JSON output with v.db.connect
|-
| [https://github.com/OSGeo/grass/pull/6801 #6801] || v.db.connect: Ends with error if both -p and -c flags are present
|-
| [https://github.com/OSGeo/grass/pull/6728 #6728] || db.select: Adding JSON and CSV support
|-
| [https://github.com/OSGeo/grass/pull/6703 #6703] || doc: Enable MathJax rendering for equations in MkDocs documentation
|}

GRASS GSoC Ideas 2026

2026-05-05T03:27:52Z

Gulshan: Add Gulshan's GSoC wiki page

== About ==
Important: While we are still an OSGeo project, we changed our fiscal sponsor to [https://numfocus.org/ NumFOCUS].

''As a result, GRASS participates in GSoC under the [https://numfocus.org/ NumFOCUS] umbrella organization.''

Read more about our governance [https://grass.osgeo.org/about/governance/ on GRASS website].

* [https://numfocus.org/programs/google-summer-code The NumFOCUS GSoC main page]
* [https://github.com/numfocus/gsoc/blob/master/CONTRIBUTING-contributors.md NumFOCUS guidelines for contributors].
* [https://summerofcode.withgoogle.com/ Official GSoC page at Google]

== Accepted ideas ==
=== Idea title ===
* Student:
* Mentors:
* [[GRASS_GSoC_2025_Add_JSON_output_to_different_tools_in_C|Example of Wiki page]]

=== Support writing tests with pytest ===
* Student: Gulshan Kumar
* Mentors: Vaclav Petras, Corey White
* [[GRASS_GSoC_2026_Support_writing_tests_with_pytest|Project Wiki Page]]

== AI Tool Usage Policy ==
We acknowledge that applicants may use AI tools (like ChatGPT, Copilot, etc.) to assist with proposal writing and coding. However:

* Your proposal should reflect your own understanding and voice. AI-generated "slop" (overly generic or regurgitated content) is easy to spot and will hurt your application.
* We evaluate applications primarily on GitHub contributions and communication with the GRASS community, not just proposal polish.
* Show us you understand the project through high-quality pull requests on GitHub.
* Disclose AI usage: If you use AI tools in your proposal or code contributions, please disclose the extent to which you used them (e.g., for brainstorming, proofreading, code suggestions, etc.).

== Ideas ==
If you are a student you can suggest a new idea or pick up an existing one. In any case write about it to [https://discourse.osgeo.org/c/grass/developer/61 OSGeo Discourse forum for GRASS developers], [https://github.com/OSGeo/grass/discussions GitHub Discussions], or [https://gitter.im/grassgis/community Gitter].

You are invited as well to have a close look at ideas from previous years ([https://trac.osgeo.org/grass/wiki/GSoC/2014 2014], [https://trac.osgeo.org/grass/wiki/GSoC/2015 2015], [https://trac.osgeo.org/grass/wiki/GSoC/2016 2016],
[https://trac.osgeo.org/grass/wiki/GSoC/2017 2017],
[https://trac.osgeo.org/grass/wiki/GSoC/2018 2018],
[https://trac.osgeo.org/grass/wiki/GSoC/2019 2019],
[https://trac.osgeo.org/grass/wiki/GSoC/2020 2020],
[https://trac.osgeo.org/grass/wiki/GSoC/2021 2021],
[https://trac.osgeo.org/grass/wiki/GSoC/2022 2022],
[https://trac.osgeo.org/grass/wiki/GSoC/2023 2023])
which have not yet been implemented.
You can also look at accepted GRASS GSoC [https://trac.osgeo.org/grass/wiki/GSoC projects from previous years] for an idea of scope.''

=== Parallelization of existing tools ===

There are several tools that would benefit from parallelization with OpenMP, e.g. r.texture, r.fill.stats, r/v.surf.idw, r.viewshed, v.to.rast, r.grow.distance, v.surf.bspline, r.proj, ...
For overview of current state, see [[Raster_Parallelization_with_OpenMP]].

* Requirements: familiarity with C, OpenMP
* Mentor: Huidae Cho
* Co-mentor: Vaclav Petras, Anna Petrasova
* Project length: Large (350 hours)
* Rating: difficult
* Expected Outcomes: parallelized 2-5 tools, depending on complexity
* Test of skills (one or more):
** Address https://github.com/OSGeo/grass/issues/5776 (carefully read the existing conversation in the issue and linked PR)
** Pick a tool and develop prototype implementation of the parallelization.

=== Improve GRASS user experience in Jupyter Notebook ===
[[File:Jupyter_interactive_viewshed.png|500px|thumb|right|InteractiveMap in grass.jupyter library]]
Python package [https://grass.osgeo.org/grass-stable/manuals/libpython/grass.jupyter.html grass.jupyter] was developed during [https://trac.osgeo.org/grass/wiki/GSoC/2021/JupyterAndGRASS GSoC 2021] to simplify running GRASS from Jupyter Notebooks and displaying data. This project could focus on adding features such as better symbology handling and adding legend to InteractiveMap and better integration with matplotlib.

* Requirements: Python
* Mentor: Anna Petrasova
* Co-mentor: Vaclav Petras, Helena Mitasova, Corey White
* Project length: Large (350 hours)
* Rating: easy to medium
* Expected Outcomes: improved user experience when using GRASS through notebooks
* Test of skills: write a test for [https://github.com/OSGeo/grass/tree/main/python/grass/jupyter grass.jupyter library] using python unittest or pytest, more info [https://grass.osgeo.org/grass-devel/manuals/libpython/gunittest_testing.html here] or rewrite some of the functions in grass.jupyter library using the new [https://grass.osgeo.org/grass-devel/manuals/python_intro.html#running-tools Tools API].

=== Add JSON output to different tools ===
There are several tools in GRASS that would benefit from a JSON-formatted output.
Besides adding the JSON output, the work would also include adding tests and basic documentation.
* Requirements: C, Python
* Mentor: Vaclav Petras
* Co-mentor: Anna Petrasova, Corey White
* Project length: Large (350 hours)
* Rating: easy to medium
* Expected Outcomes: 10-20 tools (depending on project length and complexity of the tool) tools with well tested JSON output
* Note: A lot of work on JSON was already done, but there is more! Some of the remaining tools require more design. There are also Python tools (not just C which was the focus previously) and then also the grass-addons repo. Some tools also don't have any machine readable output right now and should. Also current tools which use other tools should use the new JSON as opposed to what they are using now. Preparing a well-reasoned list of tasks is a part of the application.
* Test of skills (pick one or more):
** https://github.com/OSGeo/grass/issues/6968
** https://github.com/OSGeo/grass/issues/6969
** https://github.com/OSGeo/grass/issues/6970

=== Support writing tests with pytest ===

* The current testing framework, ''[https://grass.osgeo.org/grass-stable/manuals/libpython/gunittest.html grass.gunittest]'', was written before migration to Git/GitHub and when long free runs in 3rd party services were unthinkable. Additionally, some no longer relevant goals were prioritized, such as independence on the current code, detailed custom HTML reports, success tracking over time, and high specialization towards GRASS-specifics.
* ''grass.gunittest'' is based on Python ''unittest'' package and many projects since then migrated to //pytest//, e.g., GDAL and Numpy. While ''unittest'' is inspired by Java's JUnit, ''pytest'' is designed to support writing small, readable tests, and uses plain `assert` statements instead of many different assert methods.
* Using ''pytest'' should lead to tests which feel more like Python scripts and to minimum of testing-specific code.
* An example issue of ''grass.gunittest'' is that it doesn't work well with tests of the main GRASS executable (prominence of `grass ... --exec` is yet another new thing which changed since ''grass.gunittest'' was designed).
* Two main things needed:
** Create general comparison functions from the ''grass.gunittest'' assert methods so that they can be used with pytest.
** Current grass.script.setup.init function and grass.script.core.create_location function don't work well in the context of a pytest test function. More
* Additional things needed:
** Fixture for pytest to set up and tear down a GRASS session in a temporary mapset.

* Requirements: Python
* Project length: Large (350 hours)
* Mentor: Vaclav Petras
* Co-mentor: Stefan Blumentrath
* Proposed by: Vaclav Petras
* Rating: easy to medium
* Expected Outcomes: Convenient way of writing tests with pytest
* Test of skills: Fix failing tests and/or write new tests (more is better). Alternatively, addressing a smaller problem in the testing framework is a good task, too.

=== Fix known code defects ===

* Fix code defects (security or code quality) such as those reported by Coverity Scan.
* Mentors: Vaclav Petras
* Co-mentors: Nicklas Larsson
* Proposed by: Vaclav Petras
* Project length: Large (350 hours)
* Rating: medium
* Requirements:
** Language: C
** Proposal: Define milestones which will be used during the evaluation.
* Expected outcomes:
** Reduction of issues by 70-100%.
** New tests for changed code if missing.
* Test and training tasks (complete more than one): Fix e.g., [https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html GCC Static Analysis], [https://clang.llvm.org/docs/ClangStaticAnalyzer.html Clang Static Analyzer] or [https://cppcheck.sourceforge.io Cppcheck] issues.

=== Subcommand CLI for GRASS ===

* Make running of GRASS tools in command line as easy as possible.
** `grass run r.slope.aspect elevation=elevation.tiff slope=slope.tiff aspect=aspect.tiff`
* Project length: Large (350 hours)
* Rating: medium
* Requirements:
** Language: Python
** Proposal: Student needs to show sufficient understanding of data and project handling in GRASS. Furthermore, the proposal needs to present, at least, concrete formulation of ideas, identification of missing and existing parts, and new subcommands.
* Mentors: Vaclav Petras
* Co-mentors: Stefan Blumentrath, Corey White
* Proposed by: Vaclav Petras
* Expected outcomes:
** A subcommand which runs a GRASS tool on GeoTiff and GeoPackage in one step.
** A complete parity with the existing CLI.
** An underlying Python API which will be used to implement the CLI.
* Test and training tasks (complete one or more): Add a subcommand, sub-subcommand, or an option to the experimental interface (with tests).
** Add `--region` to set a temporary computational region for the execution, e.g. `--region="raster=raster_name"`.
** Add `--import-raster=some/file.tiff` which imports (r.import) a raster file (same for vector and similarly for export).
** Add `--link-raster=some/file.tiff` which links (r.external) a raster file (same for vector and similarly for r.external.out).

Current state:

# Reveals the existing subcommands
PYTHONPATH=$(grass --config python-path) python -m grass.app --help
# Allows running subset of commands
grass run --help


=== GUI: Add space-time datasets support in Data Catalog ===
[[File:GUI_data_tab.png|400px|thumb|right|Data catalog]]
Currently GRASS Data Catalog shows only raster and vector maps. The goal of this project is to add support for space-time datasets. It is mainly space-time raster datasets. In the next phase of the project support for other types of space-time datasets (vector and 3D raster) could be added. Besides displaying space-time datasets in the layer tree, it is also about adding the equivalent functionality currently available for raster and vector layers from the context menu.

* Requirements: familiar with Python
* Project length: Large (350 hours)
* Mentor: Martin Landa
* Co-mentor: Anna Petrasova
* Proposed by: Martin Landa
* Rating: medium
* Expected Outcomes: 175 hours basic support for space-time raster datasets; 350 extended support also for other space-time datasets types (vector, 3D raster)
* Test of skills:
** suggest/implement solution for completing https://github.com/OSGeo/grass/issues/2599

=== Searchable metadata in Space Time Datasets ===
The temporal framework in GRASS was initially developed almost 15 years ago. Spatio-temporal data has become more widely available since then and new standards emerged like e.g. ''[https://docs.ogc.org/cs/25-004/25-004.html STAC]'' with ''[https://github.com/stac-extensions/stac-extensions.github.io extensions]'', or the ''[https://cfconventions.org/ CF-conventions]''. The aim of this project is to extend the metadata model in the temporal framework to improve discoverability of map datasets registered in TGIS and to allow users to embed extended metadata with the registered maps in a Space Time Dataset in a searchable way. Ideally, the new model is able to account for the standards mentioned above.

See also: https://github.com/OSGeo/grass/issues/1938

* Requirements: Python, SQL, JSON
* Project length: Large (350 hours)
* Mentor: Stefan Blumentrath
* Co-mentor: ???
* Proposed by: Stefan Blumentrath
* Rating: medium
* Expected Outcomes:
** an updated TGIS database model (version 4) that:
*** is oriented on relevant metadata standards (STAC, CF-Convention, ...)
*** allows to use metadata in temporal_where to select relevant elements of Space time datasets
** updated tool to create space time datasets (t.create) in the TGIS database with extended metadata
** updated tool to register map datasets (t.register) in the TGIS database with extended metadata
** Conversion tool for database Upgrades (v3 to v4)
** a new tool to update / modify metadata in the TGIS database
** Storage of timeseries metadata for both C-based and temporal Tools

* Test of skills (e.g.):
** address one or more sub-tasks from https://github.com/OSGeo/grass/issues/3427 (add append-mode to selected new tool(s))
** suggest/implement solution for https://github.com/OSGeo/grass/issues/3394 (more complex task)
** suggest/implement solution for https://github.com/OSGeo/grass/issues/7041

=== Add {your research idea} to GRASS ===

* In general, you can propose any topic, but you can specifically propose integrating your research or research idea into GRASS.
* Requirements:
** Language:
*** Depends on the project, often Python, sometimes C.
*** Adding your latest ecological analysis
** Proposal:
*** Discuss relevance to GRASS.
*** Describe technical steps needed for integration.
*** Describe whether it is an addition of a tool (module) or a change in one of the libraries. If it is a tool, specify if it should be included in the core grass repository or in grass-addons repository and why.
*** Specify what research was done and what needs to be accomplished in order to have usable product at the end of summer.
*** Specify who will provide the research expertise.
* Project length: Large (350 hours)
* Rating: from low to hard
* Mentors:
** GRASS project will provide technical mentors, but it is up to the applicant to ensure the research part is mentored well. An exception may be granted to applicants which can demonstrate that the research is finished or that they have enough expertise themselves.
** Possible technical mentors: Vaclav Petras, Anna Petrasova
** Research mentors: Bring in an expert from your field, e.g., your academic advisor or project principal investigator (if needed).
* Proposed by: Vaclav Petras
* Expected outcome: Working feature which is integrated and merged at the end of the project.
* Test and training tasks:
** Create a test in Python for an existing tool in the grass-addons repository or in the core grass repository.

=== Title of idea ===

Description here

* Requirements:
* Project length: (175 or 350 hours)
* Mentor:
* Proposed by:
* Rating:
* Expected Outcomes:
* Test of skills:
* Other:

== Tips for students ==
* Follow official [https://github.com/numfocus/gsoc/blob/master/CONTRIBUTING-contributors.md NumFOCUS guidelines].
* Include "GRASS" in the title of our idea to easily distinguish ideas and projects inside NumFOCUS.
* If you have your own ideas we encourage you to propose them. Explain them on the [https://discourse.osgeo.org/c/grass/developer/61 on our Discourse].
* Follow some good practices in your ideas and proposals:
** Stress why the project would be useful.
** Show that you know how you will proceed. That is, make sure that you can demonstrate that the proposal is feasible in the given time frame.
** Be specific in the implementation (or at least as specific as you can).
** Explain what the final product will look like and how it will work. You can add drawings or mock-ups.
** Explain how the idea relates to existing GRASS functions, features, and needs.
** Do not include steps such as "install GRASS", "compile GRASS libraries (on my machine)", "read about the API". You should do this before applying to GSoC.
* Compile GRASS from source and prepare environment for development:
** Read [https://github.com/OSGeo/grass/blob/main/CONTRIBUTING.md CONTRIBUTING file].
* Prove your worth by being active on the [https://discourse.osgeo.org/c/grass/developer/61 GRASS Discourse] or other channels ([https://github.com/OSGeo/grass/discussions GitHub Discussions], fix some [https://github.com/OSGeo/grass/issues bugs], and/or implement some (smaller) features, or write some (simpler) GRASS module, and post it to mailing list. There's no better way to demonstrate your willingness and abilities. Do this before start you apply to GSoC.
* Also note that fixing existing bugs and/or implementing enhancements will be a part of student evaluation.

{{GSoC}}

GRASS GSoC 2026 Support writing tests with pytest

2026-05-05T03:22:35Z

Gulshan: Created page with "{| class="wikitable" | '''Student Name''' || Gulshan Kumar |- | '''Organization''' || [https://numfocus.org/ NumFOCUS] |- | '''Mentor Name''' || Vaclav Petras, Stefan Blumentrath |- | '''GitHub Fork''' || [https://github.com/gulshan-123/grass View Repo] |- | '''LinkedIn Profile''' || [https://www.linkedin.com/in/gul-shan123 View LinkedIn] |} = Abstract = The current test framework in GRASS, gunittest, was designed before GitHub era. Based on Python unittest, it has seve..."

{| class="wikitable"
| '''Student Name''' || Gulshan Kumar
|-
| '''Organization''' || [https://numfocus.org/ NumFOCUS]
|-
| '''Mentor Name''' || Vaclav Petras, Stefan Blumentrath
|-
| '''GitHub Fork''' || [https://github.com/gulshan-123/grass View Repo]
|-
| '''LinkedIn Profile''' || [https://www.linkedin.com/in/gul-shan123 View LinkedIn]
|}

= Abstract =
The current test framework in GRASS, gunittest, was designed before GitHub era. Based on Python unittest, it has several distinct types of assertion methods and requires tests to be executed from within a GRASS shell session. This has steep learning curve and is far from modern testing methods which uses Pytest.

This project aims to modify the GRASS test by shifting the testing framework to pytest. Pytest uses simple and plain assert statements, fixtures, and is more readable. The project will involve designing a new API for several grass related assertions, implementing fixtures to handle GRASS sessions and temporary mapsets outside of the GRASS shell, integrating sample datasets, and iterative refactoring (utilizing tools like Bowler) to migrate existing tests. Thus, this will result in a more Pythonic, accessible, and maintainable testing environment for GRASS contributors.

= Project Scope =
# API Design: Designing how GRASS specific assertions (like rasterExists) will look in pytest. We will draw inspiration from NumPy/GDAL own migration history.
# Session & Mapset Fixtures: Designing pytest fixtures to handle GRASS session setup and teardown. This also include running pytest outside of a GRASS session.
# Isolation: Tests must be isolated to ensure there is no side effects between them. We will decide on per file/per function isolation.
# Sample Dataset Integration: Addressing the dependency on the NC SPM sample dataset from grass.gunittest to the pytest framework.
# Iterative Refactoring Strategy: Defining the location for the new tests (tests or testsuite directories) and utilizing AST-based refactoring tools like Bowler (combined with AI agents) to automate the migration of existing tests.
# Contributor Documentation: Creating a user friendly testing guide for future contributors to encourage rapid adoption of the new pytest framework.

= Timeline =
{| class="wikitable"
!Period !! Timeline !! Tasks !! Status
|-
| Community Bonding Period
||
May 1 - May 24, 2026
||
# Finalize the API design for the new assertion functions alongside mentors.
# Research NumPy and GDAL transition to pytest for more insights.
# Engage with the community to establish conventions for the new tests structure.
||
|-
| rowspan="13" | Official Coding Period
|-
| '''Week 1''' (May 25 - May 31) ||
# Implement fixtures to allow pytest execution outside the GRASS shell in conftest.py.
# Fix grass.script.setup.init behavior.
||
|-
| '''Week 2''' (June 1 - June 7) ||
# Implement function/module scoped fixtures for temporary mapset creation and teardown. Ensure environment isolation.
||
|-
| '''Week 3''' (June 8 - June 14) ||
# Begin translating basic gunittest assertions to pytest equivalents.
||
|-
| '''Week 4''' (June 15 - June 21) ||
# Implement complex geospatial comparison functions (e.g., vector/raster fitting).
||
|-
| '''Week 5''' (June 22 - June 28) ||
# Work on integrating the NC SPM sample dataset into the new pytest architecture.
||
|-
| '''Week 6''' (June 29 - July 5) ||
# Finalize dataset integration.
# Write unit tests for the new pytest fixtures and utilities to ensure framework stability.
||
|-
| style="background:#ffdead;" | '''Midterm Evaluation''' (July 6 - July 10) ||
# Submit MidTerm evaluation.
||
|-
| '''Week 7''' (July 6 - July 12) ||
# Develop automation scripts using Bowler (and AI assistance) for iterative refactoring of existing test suites.
||
|-
| '''Week 8''' (July 13 - July 19) ||
# Begin migrating test files from unittest to pytest.
# Decide on unittest class structures vs. pure functions based on mentor feedback.
||
|-
| '''Week 9''' (July 20 - July 26) ||
# Continue iterative migration, focusing on tests that failed or interacted poorly with grass --exec.
||
|-
| '''Week 10''' (July 27 - August 2) ||
# Draft the User Guide for contributors on how to write tests using the new pytest framework.
||
|-
| '''Week 11''' (August 3 - August 9) ||
# Address edge cases, fix failing tests resulting from the migration, and ensure CI pipelines are green.
||
|-
| '''Week 12''' (August 10 - August 16) ||
# Buffer week. Code cleanup, finalizing PRs, and reviewing documentation.
||
|-
| Final Week
| August 17 - August 24
|
# Submit Report, Project, Blog and Documentation
|
|}

= Reports =
== Community Bonding Period ==

= Log of Pull Requests =
{| class="wikitable"
! PR !! PR Title
|-
| [https://github.com/OSGeo/grass/pull/7071 #7071] || g.parser: Missing support G_OPT_F FORMAT in python %option
|-
| [https://github.com/OSGeo/grass/pull/7051 #7051] || t.vect.list: Added support for JSON, YAML and CSV
|-
| [https://github.com/OSGeo/grass/pull/7004 #7004] || grass.jupyter: use json output format in timeseriesmap
|-
| [https://github.com/OSGeo/grass/pull/6971 #6971] || db.columns: added format list and format=csV
|-
| [https://github.com/OSGeo/grass/pull/6933 #6933] || db.columns: added support for -e to print more column information
|-
| [https://github.com/OSGeo/grass/pull/6867 #6867] || v.info: Add format csv with c flag and sync with v.db.connect
|-
| [https://github.com/OSGeo/grass/pull/6823 #6823] || v.info: Sync -c flag with format=JSON output with v.db.connect
|-
| [https://github.com/OSGeo/grass/pull/6801 #6801] || v.db.connect: Ends with error if both -p and -c flags are present
|-
| [https://github.com/OSGeo/grass/pull/6728 #6728] || db.select: Adding JSON and CSV support
|-
| [https://github.com/OSGeo/grass/pull/6703 #6703] || doc: Enable MathJax rendering for equations in MkDocs documentation
|}