Beginning Sprint 6.3, Christina discussed assigning us task UW-192. UW-192 gives us a nice transition from writing test cases to using these test cases to confirm the code we'll be writing this week Is working properly. Currently we are calling Jinja2 - the text-based template language - directly. Our goal for UW-192 will be to replace these direct calls with calls to our Jinja Template Class (created within Sprint 6.2 - UW-191 ticket).
The main Idea Is last week we had code written and needed to create test cases to ensure It was working properly. Now we need to update code that already has test cases written, and If the updated code Is accurately representing what the methods did previously, It should continue to pass the test cases.
What Is the task? And the description of the task
Task: As a developer, I need a more generalized standalone tool to handle namelist templates.
Description:
This work is to refactor the templater.py tool
The existing user-facing fortran namelist tool does much of the work of the Template Class as part of its implemented code. In the existing tool the direct calls to Jinja2 need to be replaced with calls to the Template Class (upon successful completion of UW-191)
The resulting Tool should follow the design outlined in Template Tool Design Doc in the Description section
Additional Info:
Terry added a comment - 26/Sep/22 - A working code example for a namelist parsing tool set_namelist.py can be found in the code_examples branch
What does this mean?
From a quick read of the description I had several follow-up questions:
Are we taking our templater.py file and changing it to Incorporate our new Jinja Template Class? This would make sense since the description says 'replace the direct calls to Jinja2 need to be replaced with calls to the Template Class'
In our Tagup with Christina we were able to confirm that our assumption on updating the templater.py file and changing it to Incorporate our new Jinja Template Class was correct. She was also able to give us a brief walkthrough of templater.py that helped us greatly to understand where we would need to be making edits and other sections that we could leave as Is. We found that the majority of the code that needed to be replaced would fall between lines 88 - 118. This gave us enough Information to begin working on UW-192.
Additionally, we rescheduled our regular Tagup from Tuesday, 10/18 to Thursday, 10/13 instead since Christina would be out of office.
Breakdown:
We had two different files: templater.py, and test_templater.py
templater.py - previously had already done most of the work in a main function, but we needed to change it to incorporate Jinja so if the system changed it wouldn’t break the code. This Involves replacing direct calls to Jinja2 with calls to the Jinja Template Class
test_templater.py - currently has our test cases for templater.py. These should still work after our edits to templater.py
Emily and I started UW-192 by looking at templater.py and test_templater.py. After speaking with Christina, we knew that templater.py still needed to pass the test cases outlined in test_templater.py. This gave us an easy idea where to start, if we edited templater.py and began to fail the pytests then we would know right away that our code was not implemented correctly. We attempted to start small and edit one line, but after looking at the code that followed we found we needed to change larger portions of It at once.
Soon we were able to make the connection to each line of code and realize that we had a method in the Jinja Template Class that could easily replace the current line(s). For example, looking at lines 88 to 93:
88 # instantiate Jinja2 environment and template
89 env = Environment(
90 loader=FileSystemLoader(user_args.input_template),
91 undefined=StrictUndefined,
92 )
93 template = env.get_template('')
We could see that these lines could be simplified down to "template = J2Template(cfg, user_args.input_template)." The __Init__ method In the Jinja Template Class creates an Instance of the template using the cfg object and user_args.Input_template. I felt confident in determining which lines we would be changing and which would be staying the same. Image 1 highlights the edits on the templater.py file. By replacing direct calls to Jinja2 with calls to the Template Class we were able to condense the lines of code In our file.
Emily and I found we had differing Information from our Tagup with Chrisitna. Emily had noted that the print statements(Image 1 - highlighted in green on the righthand side, lines 93 - 95, 100 & 105) should be removed from templater.py, but I had noted they should be kept the same. I decided to look at the test cases to ensure that if we removed these lines the tests would not break. After viewing the test_templater.py we saw that these print statements were essential to passing. The test cases were checking if the print statements returned from the methods in templater.py were equal to the string 'outcome' in test_templater.py. This gave us confirmation to leave the print statements in and reconfirm our assumption with Christina In our Thursday Tagup.
Image 1 - Edits on templater.py
We confirmed with Christina our code looked good and to leave in the print statements. Now we could create a PR and then the team would check it and approve it if all looked good. We left the Tagup with the task of looking ahead to Sprint 6.4 & Sprint 6.5 to see if we could pull a task forward to work on next week and then discuss with the team during our Friday DSM.
To finish up UW-192, we needed to create PR and push our code to the workflow-tools repository. I had already experienced this process within Sprint 6.2 on UW-191, and decided to ask Emily if she wanted to 'drive' and Implement this process. We confirmed that we were passing the pytests, and pylinter for both uwtools and tests. Next, I was able to walk her through the process of creating a PR and sent her some documentation Christina sent me on formatting the PR correctly so it meets the standards the team has set in place.
Pull Request(PR) criteria:
Open PRs with a title that has the Jira Ticket number in it, along with a description of the change.
Example: "UW-### Add Jinja Template Class and Tests"
Add a description in the body of the PR. This is the only space that needs to be edited in the template provided when you push to GitHub.
Leave all other spaces as-is and then just check the marks on the lists when the PR is open.
Once we finished setting up the PR, we submitted It for review.
In the DSM we shared that we had completed UW-192 and were awaiting review on GitHub. Christina was also awaiting review on GitHub on UW-151. The team had previously decided once a story had received at least two comments for feedback from the team, then If nothing else needed to be changed the task could be merged Into the develop branch. UW-151 had been blocked since Sprint 6.2 from being moved Into the 'done' phrase because It required more feedback from the team. This Is due to the team being assigned ECC Release Train tasks that are required to be completed throughout the next two weeks at different deadlines, making It hard to keep the Sprint on track. Christina proposed since Emily and I are also part of the team that we could potentially give her feedback on UW-151, which would allow her task to be merged Into the develop branch.
Reviewing UW-151:
I was able to review Christina’s code by reviewing the five files that she changed. The description of UW-151 Included adding an extension to the PyYAML SafeLoader that enables the !INCLUDE tag with a list of potential yaml files to be included in the resulting parsed YAML file. This new feature add is a non-breaking change which adds functionality to what already exists. I felt that UW-151's task was outside of my scope of understanding since I am not familiar with YAML syntax. Without more knowledge of the task, I wasn't able to contribute on topic specific changes, but I was able to comment on the with-statement vs. try/finally for opening/closing a file. Previously in UW-191, we saw that the pylinter didn't like try/finally and suggested using a with-statement. I agreed with Christina’s comment that the pylinter was giving us that feedback and we decided to go with the with-statement for now pending Keven’s explanation why we would want to go with try/finally instead. Again, without furthering understanding on the feature and tools being implemented I was only able to read through the documentation and comment on code styling. I found a redeclaration of a variable in the config.py file(Image 3, line 133) that I supplied feedback on, on the PR. I wasn't sure if the redeclaration of the variable filepath was essential due to future side effects in the code down the line or if we could remove this line altogether. Christina commented back on that the pylinter didn’t complain about the redeclaration of filepath, but this wasn't necessary to have the variable abs_path. She was able to remove the abs_path variable, replacing this variable with filepath directly, and was able to remove line 133.
Image 2 - UW-151 PEP-8 Standard Feedback
Image 3 - UW-151 Redeclaration of Variable Feedback
Emily and I were able to look ahead to Sprints 6.4 and 6.5 to find a multiple stories that we could potentially work on for the second week of Sprint 6.3. The two stories we were able to Identify were: UW-200 & UW-201. UW-200 had an estimated ticket value of 1-point and UW-201 had an estimated ticket value of 2-points. We decided to start with UW-200 because It was a smaller task, and given that we had a heavier load within our program, we wanted to be sure not to overload ourselves. We also noticed that we would be able to take some of our knowledge hopefully gained from UW-200 and apply It to UW-201.
Within our Wednesday DSM we were able to confirm with the team that we could officially move UW-192 Into the done phase. We also Informed the team that we had quite a few external blockers that would prevent us from completing UW-200 within Sprint 6.3 and decided that it would be our ticket for Sprint 6.4. UW-201 would be moved to Sprint 6.5. To close out Sprint 6.3, we ended with our traditional Sprint Planning & Retrospective meeting(Image 4).
Image 4 - Sprint 6.3 Retrospective
Sprint 6.4 will begin Monday, October 24th and we will begin the sprint with UW-200.