Articles on TedLawson's Bloghttps://blogs.python-gsoc.orgUpdates on different articles published on TedLawson's BlogenTue, 10 Oct 2023 01:21:59 +0000Week 18 and 19 Reviewhttps://blogs.python-gsoc.org/en/tedlawsons-blog/week-18-and-19-review/<p>Accomplishments:</p> <p>These last two weeks I was able to get all but one of my open PR's merged into the master Vorta branch. The biggest accomplishment here was competing the Test Suite Project, successfully getting the test suite to cover 80% of the vorta code base. This project took two months, and was a huge accomplishment to complete. In this project, I learned how to design a test plan, which I outlined in the original FR <a href="https://github.com/borgbase/vorta/issues/1754">here</a>. After designing the test plan, I identified areas of the code that needed the most help, and areas of the code that were the most important to test. I started with adding tests for archive and utils functions that were not previously tests, as these are core to Vorta. I then slowly expanded to cover more areas of the codebase that had opportunity for coverage. As I went through each test file, I also added parameterization where applicable to increase the number coverage of each test by adding additional positive and negative test cases. I also reorganized as I went, and created some pytest fixtures to often-repeated test setups. Finally, I added in test descriptions for each new test I created, and added in descriptions for tests that did not already have them. Now that this work is done and the coverage is at 80% of the code base, the project is officially complete.<br> <br> I was also able to complete several smaller PRs that had been hanging in limbo.</p> <p> </p> <p>Challenges:<br> <br> The biggest challenge I am facing right now is completing the final GSoC project, <a href="https://github.com/borgbase/vorta/pull/1809">Implement Profile Sidebar</a>, now that I have officially started work at Apple. I worked hard to complete most of the PRs before work started this past Monday, but was unable to make much progress with all the work I am doing with onboarding at my new job.</p> <p> </p> <p>The week ahead:<br> The sidebar project is in its final stages of development. I have talked with my mentor Manu about the remaining tasks needed, and I will work to implement these this week. Once the profile sidebar works as intended, the only remaining step will be to rewrite some elements of the testsuite that involve the profile selector to ensure they do not break with the changes I implemented. After the profile sidebar works and looks correct, and the tests are updated, the project and GSoC will be complete! </p>big.tedde@gmail.com (TedLawson)Tue, 10 Oct 2023 01:21:59 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/week-18-and-19-review/Week 16 and 17 Reviewhttps://blogs.python-gsoc.org/en/tedlawsons-blog/week-16-and-17-review/<p><strong>Accomplishments:</strong></p> <p>The last two weeks I had been interviewing for a job with Apple, and I got the position! This process took some of my time away, however I communicated this with my mentor, Manu, and also had some smaller wins in this time. First, I got two PR's merged. One was the PR that fixed an issue I discovered during my test coverage project: an issue with the Archive action buttons and the context menu buttons not being in sync, allowing for users to delete multiple archives at the same time. I outlined the bug <a href="https://github.com/borgbase/vorta/issues/1792">here</a>, and my PR that fixed the bug can be found <a href="https://github.com/borgbase/vorta/pull/1793">here</a>. Another PR I got merged in addressed a different issue I found during my testing coverage project, an issue in which users were able to do in-line renaming of archives while a background action was occurring, leading to various issues. This issue can be found <a href="https://github.com/borgbase/vorta/issues/1790">here</a>, and the PR I made to correct the issue can be found <a href="https://github.com/borgbase/vorta/pull/1791">here</a>. In addition to these PR's I also made various improvements to the <a href="https://github.com/borgbase/vorta/pull/1802">SSH box PR</a>, and continued work on the <a href="https://github.com/borgbase/vorta/pull/1809">Profile Sidebar project</a>. </p> <p> </p> <p>This week I had a productive meeting with Manu, where we discussed the current open PR's and the progress needed to get them to a place of merging. For the profile sidebar, we discussed some adjustments that can be made to the profile options buttons as well as the misc button. We also discussed the remaining work on the test suite improvements and SSH Box PR.</p> <p><br> <strong>Challenges: </strong></p> <p>The biggest challenges I faced this week were balancing my interview prep time and GSoC work. Now that I got the job offer and have completed all on-boarding work relating to the job, I can focus on the GSoC projects remaining before my start date in a couple of weeks.<br> <br> <strong>The week ahead:</strong></p> <p>The week ahead will be a big one - I plan to complete all the currently open PR's and finish up the test suite project. If all goes to plan, I could even finish up the profile sidebar project, however that will likely spill into the next week or two. Once these projects are complete, I will be able to put the finish touches on the GSoC work and begin compiling things for my final submission.</p>big.tedde@gmail.com (TedLawson)Mon, 25 Sep 2023 04:25:41 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/week-16-and-17-review/Week 15 Reviewhttps://blogs.python-gsoc.org/en/tedlawsons-blog/week-15-review/<p><strong>Accomplishments:</strong></p> <p>This week I made headwinds into the Profile Sidebar project. Specifically, I implemented the profile selector into a sidebar, removed the old profile selector GUI elements, updated the profile add/delete buttons to be separate and right aligned from the profile import/rename buttons. Additionally, I created a new "Misc" button that sits below the profile selector in the sidebar. This button opens a new interface I created that houses universal application options such as "settings" and "about". It will also eventually house a "repository management" tab, however that will be implemented in a separate PR. The idea behind these changes is to separate out the profile specific interface "archives, sources, repository, schedule" from the universal items "settings, about, repository management".</p> <p><strong>Challenges:</strong></p> <p>I had never before created a ".ui" file. so this was challenging to figure out for the first time. I was able to reuse the misc_tab ui page for the new settings tab, however I created the "about" tab UI from scratch. I used the other .ui files as reference and put the about tab together in a way that looks clean and formatted well.</p> <p><strong>The week ahead:</strong></p> <p>This week I am going to put the finishing touches on the "about" tab and begin working on the "repository management" tab (which will be a separate PR). Also, I have a few PRs open for bugs that I discovered while testing Vorta, and I will continue to work on these until they are in a position to get merged into master. <br>  </p>big.tedde@gmail.com (TedLawson)Thu, 14 Sep 2023 02:29:20 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/week-15-review/Week 14 Reviewhttps://blogs.python-gsoc.org/en/tedlawsons-blog/week-14-review/<p><strong>Accomplishments:</strong></p> <p>This week, I worked with my mentor and other project contributors to finalize a design for the profile sidebar. Additionally, I identified 3 bugs while testing Vorta this week. For each bug I discovered, I filed a bug report outlining the issue which included a brief description, a video screen capture of the bug, steps to reproduce, as well as relevant environment variables and log outputs. I also created PR's for each of these bugs that address the issues discovered and corrects them. Here are the bugs I discovered while testing, and the PR's I created to address them:</p> <p>1. The archive tab has buttons for "mount" "delete" "rename" etc, and when background actions are occurring these buttons get disabled. These actions are also available in a context menu when a user right-clicks on an archive. I discovered that the archive buttons and the context menu buttons are not disabled in sync, meaning that sometimes actions are left available in the context menu when they should be disabled due to a background operation in progress. This could lead to issues such as operations being queued for archives that have since been modified or deleted, and causes failures. To address this, I bound the toggle state of the archive tab buttons to those of the context menu buttons, such that they will always be enabled or disabled in sync. This PR can be found here: https://github.com/borgbase/vorta/pull/1793</p> <p>2. Similar to the previous issue, I found that the new "in-line rename" feature is left available even during a background operation. If a user renamed an archive during a background operation, it leads to visual bugs where, in some cases, all archives get deleted. In other cases, all archives get renamed to the newly entered name. To address this issue, I added a check in the method that handles the in-line renaming to only function when the rename button is enabled. This adds consistency to the rename behavior, and avoids the visual bugs that could be caused. My PR for this issue can be found here: https://github.com/borgbase/vorta/pull/1791<br> <br> 3. One final issue I discovered while testing had to do with the SSH Key combobox. I was testing the "add ssh key" feature when I discovered newly added keys were not populating in the box until after Vorta restarts. I found this had to do with the 'add ssh key' dialogue box not closing when the user clicks 'generate'. Instead, the box stays open to inform the user the key has been generated, and then the user has to click 'cancel' to close the box. To fix this issue, and make the behavior similar to other interactions with the SSH options, I added functionality that lets the 'add ssh key' box close after the user generates a new key, and displays the success or failure text in a message box, similar to success and failure message when the user copied ssh keys to clip board. This PR can be found here: https://github.com/borgbase/vorta/pull/1802</p> <p><strong>Challenges:</strong></p> <p>This week I faced interface design challenges. Having spent most of my time in the test suite, I am less familiar with how to implement UI changes that integrate well with the rest of the application. YF-projects had good advice for me: </p> <p>1. Recognizable patterns repeated throughout the application usually improve the UX</p> <p>2. Try to avoid cluttering the inference </p> <p>His advice helped me decide how to order the buttons/context menu actions in the archive tab. He and Manu also offered advice on the profile sidebar, and we now have a good idea of what it will look like such that I can get started on that project.</p> <p><strong>The week ahead:</strong></p> <p>This week I am going to focus my time on the profile sidebar project. My goal is to get the profile sidebar GUI elements created, and the old sidebar elements removed. From there, I will begin working on adding functionality to the elements.</p>big.tedde@gmail.com (TedLawson)Tue, 05 Sep 2023 19:13:44 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/week-14-review/Week 13 Reviewhttps://blogs.python-gsoc.org/en/tedlawsons-blog/week-13-review/<p><strong>Accomplishments:</strong></p> <p>This week I communicated with my mentor Manu that I was fielding a couple of job interviews, and as a result I was not able to accomplish as much as I normally would in a given week. That being said, I did have a couple of wins worth mentioning. Starting off, I was able to get the reduced test workflow PR merged into master last week. This has worked well in practice, and significantly reduces the number of jobs done on each push/PR. Specifically, push/pull requests now run a total of 11 checks, compared to the previous 39 that were occurring before. Push/Pull requests to master branch have had the comprehensive set of checks left in place, and the workflow I edited also leaves in place the ability to run a manual comprehensive check at any time. The result here has been that most triggers (normal push/pull requests to a branch other than master) run a thorough set of tests, they are no longer timing out, and the resource use/execution time has been reduced. </p> <p>This week I also created a PR for the final bits and pieces of the test suite revisions. I have created a few more tests, increased coverage from 77% to 79%, and generally "cleaned up" where I could. </p> <p><strong>Challenges:</strong></p> <p>This week I did not face any challenges. Mostly due to the reduced workload as I focused a majority of my time on interview prep, as communicated with my mentor.</p> <p><strong>The Week Ahead:</strong></p> <p>In the week ahead, I have some additional interview prep that I have communicated with Manu. I am ready to begin working on the next project, which involves moving the profile selector and tab widget to a sidebar, and generally rethinking the main window interface. I will create a FR and mockups to brainstorm ideas and receive feedback from the community before beginning work in earnest.</p>big.tedde@gmail.com (TedLawson)Tue, 29 Aug 2023 19:59:58 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/week-13-review/Week 12 Reviewhttps://blogs.python-gsoc.org/en/tedlawsons-blog/week-12-review/<p><strong>Accomplishments:</strong></p> <p>This week I had 6 PRs merged into master. These PR's covered the majority of the unit test folder revisions, and included:</p> <ul> <li>Reducing code duplication by implementing pytest fixtures for common test setup/teardown</li> <li>Reducing code duplication and improve readability through the use of test parametrization</li> <li>Increased total codebase test coverage from 72% to 78% (so far - more to come!) by adding creating additional unit tests</li> <li>Wrote additional docstrings to improve readability and help future contributors understand each test</li> </ul> <p><strong>Challenges:</strong></p> <p>In addition to getting these PR's merged in, I also began working on a side project which was brought to my attention by my mentor Manu. He mentioned that currently, our GitHub automated workflow is set up to run integration and unit tests on too large a matrix of [python versions X os's X Borg versions], resulting in a 39 jobs created for each push and pull request action. He tasked me with reducing this workflow by creating different matrices based on the type of job. Specifically, he requested shorter runs for Push or PR, and full runs for manual workflow dispatchs or a push to Master. I had never worked with yaml files before, so this was something new for me, but I stepped up to the task and learned a lot in the process. The main challenge I faced was getting a matrix defined dynamically as opposed to staticly. In its current form, the metric was assigned in the yaml file and was the same for all actions (push, PR, workflow dispatch). My challenge was to instead create the matrix dynamically based on the type of action. I best approach I found to doing this was to create a script that would generate the matrix and write it to a json file, which the yaml file would then store in an environment variable "GITHUB_OUTPUT" for future jobs to reference. I had two main struggles along the way:</p> <ol> <li>Deprecation warnings: Originally, I was setting the matrices using `::set-output`, however I received a warning from GitHub that this method was getting a deprecation warning from GitHub and needed to change my approach. After reading the GitHub documentation on this issue, I discovered there was a new "GITHUB_OUTPUT" environment file available, and using this was the new best practice. </li> <li>In the integration test matrix, we exclude Borg version 2.0.0b5 with python v3.8 because it isn't supported. This was challenging at first because I was not sure how to define this when I was creating matrices dynamically vs statically. I tried several different approaches, including one where I created a step in the `test_integration` job that checked if the combination was invalid and, if so, would skip the rest of the steps. This approach, however, was somewhat clunky, and one of the project maintainers recommended defineing the exclude within the script that creates the matrices. In hindsight this seemed like the obvious approach, however I think I was hung up on trying to do the exclude within the `test_integration` job, which is where the original exclude was defined. With this new approach of adding the exlclude to the matrix within the script, everything worked as intended and I marked the PR as 'ready for review'.</li> </ol> <p><br> <strong>The Week Ahead:</strong></p> <p>With these PRs merged in, the unit tests folder is almost complete, with some work left in the Misc tests and treemodel. After this I will move into integration tests and finish up the Testsuite Improvements project.</p>big.tedde@gmail.com (TedLawson)Mon, 21 Aug 2023 18:59:00 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/week-12-review/Week 11 Reviewhttps://blogs.python-gsoc.org/en/tedlawsons-blog/week-11-review/<p style="text-align: justify;">Accomplishments:</p> <p style="text-align: justify;">This week I had one PR merged, and created an additional 3 more PRs relating to the test suite cleanup and test coverage increases. Starting with the merged PR - <br> <br> - Setting for number format in archive tab #1719 - https://github.com/borgbase/vorta/pull/1719 - In this PR I created a setting in the Misc Tab that allows users to decide if they want their units of size in the archiver tab to be displayed in one fixed unit (such as all in KB or all in GB), or if they would rather have them displayed in dynamic units based on what is most appropriate for the archive size. This setting is important because some users prefer to have all files displayed in the same unit so they can easily compare archives to each other. Some prefer to have their archive sizes in a more natural display with dynamic units, so I implemented this option. After creating the setting and adding functionality to it, I also added tests for the new setting as well as cleaned up and parametrized the existing utils tests. Getting this PR merged is my first UI related change for Vorta, and I am proud to have it complete!<br> <br> Additionally, I created 3 new PRs relating to increasing the code coverage for vorta and cleaning up existing tests:</p> <div style="text-align: justify;">- PR: tests/unit/test_repo - Clean up, parametrize, and increase test coverage - https://github.com/borgbase/vorta/pull/1771</div> <div style="text-align: justify;">- PR: tests/unit/test_source: cleanup, parametrize, and increase test coverage - https://github.com/borgbase/vorta/pull/1772</div> <div style="text-align: justify;">- PR: tests/unit/test_import_export: increased test coverage - https://github.com/borgbase/vorta/pull/1774</div> <div style="text-align: justify;">Each of these PR's did a combination of cleaning up existing tests by reducing code duplication and increasing readability, as well as adding new tests to increase Vortas overall test coverage.</div> <p style="text-align: justify;">Finally, I attending the GSoC contributor final evaluation meeting for one hour on Tuesday morning where I listened to the GSoC admin discuss what we need to do to prepare for the final weeks of the program. I also scheduled and attended a meeting with my mentor, Manu, where we discussed progress on the test coverage project thus far, and where to go from here.<br> <br> Challenges:</p> <p style="text-align: justify;">Things went well this week, and I did not identify any real challenges outside of just continuing to learn how to test some of the QT widgets and tables. Mostly it was a very smooth learning experience. I am continuing to learn how to identify what needs to be tested and how to approach testing in a way that adds meaningful value to the test suite.<br> <br> The week ahead:</p> <p style="text-align: justify;">This week I believe I will be able to finish the Vorta test suite fixes. I am mostly done with the unit tests and can begin on the integration tests after that. If I am able to finish the test suite fixes this week then I will be going into next week ready for the UI projects that were part of my original proposal.</p>big.tedde@gmail.com (TedLawson)Tue, 15 Aug 2023 05:15:14 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/week-11-review/Week 10 Reviewhttps://blogs.python-gsoc.org/en/tedlawsons-blog/week-10-review/<p><strong>Accomplishments:</strong></p> <p>This week I continued work on the GSoC project involving Vorta's test suite. This project has 3 main goals:</p> <p>- Clean up the Vorta test suite </p> <p>- Reduce amount of duplicated code through use of parametrization</p> <p>- Increase code coverage from ~70% to ~80%</p> <p> </p> <p>I submitted three draft PRs this week to begin working on this:</p> <p>- PR: utils unit tests: parametrize and increase test coverage #1768</p> <p style="margin-left: 40px;">- <a href="https://github.com/borgbase/vorta/pull/1768">https://github.com/borgbase/vorta/pull/1768</a></p> <p style="margin-left: 40px;">- Description: It is possible to reduce code duplication in the utils unit tests by using parametrization. Additionally, there are a some utils functions that still needed testing. In this PR, I aim to solve both of these issues.</p> <p>- PR: archive unit tests: reduce code duplication and increase test coverage #1769</p> <p style="margin-left: 40px;">- <a href="https://github.com/borgbase/vorta/pull/1769">https://github.com/borgbase/vorta/pull/1769</a></p> <p style="margin-left: 40px;">- Description: I can reduce code duplication in the archive unit tests by using a fixture to handle the repeated setup. Additionally, there are a some `archive_tab` methods that still needed testing. In this PR, I aim to solve both of these issues.</p> <p>- PR: diff unit tests: increase test coverage #1770</p> <p style="margin-left: 40px;">- <a href="https://github.com/borgbase/vorta/pull/1770">https://github.com/borgbase/vorta/pull/1770</a></p> <p style="margin-left: 40px;">- Description: There are some areas of opportunity in the `diff_result` module for increased test coverage of some class methods and functions. The `test_diff` module is already well parametrized and does not have a notable amount of code duplication, so here I would like to focus mainly on increasing code coverage.</p> <p><strong>Challenges:</strong></p> <p>The biggest hurdle I faced this week was my lessening my knowledge gap when it comes to working with PyQt. As I began writing unit tests for functions and methods, I found myself reading a lot of the documentation in order to understand how to properly test the different Qt elements. For example, when I was testing how to double-click on an archive name in the archive tab, I had to find out how to get the QPoint (a set of x-y coordinates) that I wanted to double click. To do this, I had to retrieve the item from the table, get the coordinates of the four sides of the rectangle that made up the item, and then double click the "center" of those points. I am still getting used to tables and and models, so the more experience I can get testing these UI elements for proper functionality the better.</p> <p><strong>The week ahead:</strong></p> <p>In the next week I have a GSoC meeting Tuesday with the coordinators of the program. During this meeting they will outline the final weeks of the program and how to begin getting a portfolio of all of our contributions together for display on the GSoC website after the program is over. I will continue to work my way through the rest of the test files and reduce code duplication, clean up tests where possible, and add additional functionality. I plan on continuing to do one PR for each test module as this keeps things very clean and will hopefully result in quicker approvals and merging. </p>big.tedde@gmail.com (TedLawson)Mon, 07 Aug 2023 05:18:39 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/week-10-review/Week 9 Reviewhttps://blogs.python-gsoc.org/en/tedlawsons-blog/week-9-review/<p><strong>Accomplishments:</strong><br> <br> This week, I finished up the Borg test suite changes and got 3 PR's merged into Borg master. They are as follows:<br> <br> PR: `testsuite/platform.py` conversion to pytest + remove `BaseTestCase` - https://github.com/borgbackup/borg/pull/7743 - This is one of the last remaining files in the test suite to have quite a bit of unittest and <code>BaseTestCase</code> usages, so I split it into its own PR. Here I converted all unittest to pytest, removed <code>BaseTestCase</code> entirely, and renamed some tests to follow the naming conventions of the classes they are being pulled from. Additionally, I split the `platform.py` test file into three subfiles: `platform_darwin`, `platform_linux`, and `platform_posix`. The original `platform` test file is now used to host tests that run on all platforms, and carries a collection of common pytest.mark.skip definitions that can be used by the other platforms. </p> <p>PR: `platform_freebsd.py` dummy test file - https://github.com/borgbackup/borg/pull/7748 - Created a dummy file for ACL testing FreeBSD. Relates to issue <a href="https://github.com/borgbackup/borg/issues/7745">#7745</a>. - Created at the request of one of my mentors, Thomas, who recommended starting a dummy file with tests that are skipped due to not being implemented yet. These tests will be implemented at a future date.<br> <br> PR: Remove BaseTestCase from `testsuite/` - https://github.com/borgbackup/borg/pull/7742 - Now that the `ArchiverBaseTestCase` has been removed from `testsuite/archiver/__init__.py`, I now removed `BaseTestCase` from the `testsuite/__init__.py`. After @ThomasWaldmann's recent update to the `BaseTestCase`[here](https://github.com/borgbackup/borg/pull/7736), all that remained were a few assert methods that seem superfluous and could be replaced with the built-in python asserts. - This PR removed all remaining unittest and BaseTestCase from the testsuite folder, outside of the Borg selftest which relies on unittest.<br> <br> <strong>Challenges:</strong></p> <p>This week I did not hit many roadblock - I am comfortable with the Borg testsutie at this point that I made most of these changes quickly and without too much assistance needed to get them merged quickly. As I move on to Vorta's test suite I imagine this background will come in very handy.</p> <p><strong>The week ahead:</strong></p> <p>I've talked about moving into Vorta's test suite a lot over the last few weeks, and then there was always something else that needed to be done with Borg! I can say with a lot of confidence that Borg's test suite is where we set out for it to be and I am proud of the work that has been accomplished there, with the massive amount of help from Thomas and the other contributors along the way. It feels good to have everything merged in and the test suite in a. really good place now. I have begin writing tests for the VOrta test suite and keeping them locally on my machine until the integration tests PR that is being worked on by Jetchirag is merged into master. So far I have completed some utils tests and plan to work on Scheduler and Notifications next, as there is some quick gains to be made here. </p>big.tedde@gmail.com (TedLawson)Tue, 01 Aug 2023 05:27:31 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/week-9-review/Week 8 Reviewhttps://blogs.python-gsoc.org/en/tedlawsons-blog/week-8-review/<p><strong>Accomplishments:</strong></p> <p>Last week I was able to get the Archiver folder changes merged into Borg, which was a huge victory that took weeks to finish. This PR included over 6k lines of code, and completely removed the ArchiverBaseTestCase and all elements of unittest from the archiver test suite. After getting this merged, I started a new PR that worked on improving the merge by removing some redundant code and ensuring more consistency across the test suite, which was a big goal of the outline for this project. That PR was a little over a thousand lines and also got merged, meaning the archiver test folder is officially complete! On Friday I had a meeting with Manu to discuss some of the issues I was still having with testing on live Borg binaries and also to talk about work on Vorta's test suite.<br> <br> <strong>Challenges:</strong></p> <p>This past week was one of many accomplishments, and I cannot overstate how big of a person victory it was for me to get the Archiver folder changes merged into Borg. However, I hit a serious roadblock when it came to testing on a Borg.exe binary. I was under the impression that to test on an '.exe' file I needed to have a virtual windows machine running on my Mac and ssh into it to run the tests, and I was having difficulties setting this up because the Borg vargrantfile was intended to be used with virtualbox, which does not support apple silicon arm64 architecture. Thankfully, my mentor Manu showed me Friday how simple it was to run tests on a Borg binary, and that the vagrant stuff was all a bit of a red herring that I was misunderstanding. After compiling a binary and getting the test suite to utilize it, I was finally able to see all 700+ tests pass without skipping the 200+ binary archiver ones. Previously, I relied on the GitHub CI to run these tests, and now I was able to test them myself.</p> <p><strong>The week ahead:</strong><br> As I am writing this post a bit late,  Week 9 is already in full swing. I have spent some time working with the other GSoC contributors assigned to Borg and Vorta and checked out their branches locally to run and test the changes they have been making. I will continue to work with them and assist in ways that add value to their projects. Additionally, I am working to remove the last of the Unittest and BaseTestCase elements from the Borg `testsuite/` folder, a much smaller task now that the `testsuite/archiver/` folder is already complete. Finally, I am excited to continue working to improve Vorta's test coverage. I have already shown Manu a couple small tests and they looked good to him, so I am ready to get more tests started for Vorta, while also giving time for Jetchirag to finish his test suite changes. </p>big.tedde@gmail.com (TedLawson)Thu, 27 Jul 2023 04:53:11 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/week-8-review/Week 7 Reviewhttps://blogs.python-gsoc.org/en/tedlawsons-blog/week-7-review/<p><strong>Accomplishments</strong>:</p> <p>This week saw the merging of two PR's, one was the archiver test file which I parameterized and removed the unittest elements. The other was the repository test file which I converted from unittest to pytest and created fixtures to replace the setup and teardown methods. These are two files that I had finished a while ago but took some time to get them to a place where they were ready to be merged, and I am very happy to see them finally complete! I spent most of the week thereafter going through the archiver commands folder of tests that I had completed the previous week. My goal was to do a bit a of a quality check and ensure that I did not break any functionality of the tests in the process of converting them away from unittest to pytest. Additionally, I gathered feedback my from mentor Thomas and implemented several fixes based on his review. The archiver commands folder is now in a really good place, and I will continue to follow feedback from Thomas until that PR is able to be merged.</p> <p><strong>Challenges:</strong></p> <p>I definitely found myself hitting a couple roadblocks this week when trying to address feedback from Thomas. The first was building a binary for my tests to run on locally. I followed the instructions from the Borg documentation and took at look at the Vagrantfile, and was able to get the `Borg.exe` file created, however whenever I tried to run the tests with the binary I would get an error that the file was not found. I put a pause on this for now, but will do more research to overcome this issue and finally be able to run the tests on a binary.<br> My second roadblock came when I tried to pass `pytest_generate_tests`a list of `kinds` of tests that needed to be generated. Some test files only need local archivers, however some run each test on a combination of local archiver, remote archiver, and binary archiver, and the idea was to pass a list of `kinds` needed to `pytest_generate_tests` after it was imported to each test file. Ultimately, however, I ran into issues because it does not appear that this is a function that be called and passed a list the way other functions can be. My mentor recommended using a lambda function Orr `partial` to make it happen, but I was unsuccessful and will continue to work on this.<br> <br> <strong>The week ahead:</strong></p> <p>As things get buttoned up with the Borg test suite, I am ready to move on to my next project: Improving Vorta's Test Coverage. This week I will create a coverage report and submit my findings and outline a proposed solution in a GitHub FR. I will then receive feedback and begin working on adding unit tests and parameterization where needed with the goal of improving Vorta's test coverage from its current standing of 72% to a goal of ~80%.</p>big.tedde@gmail.com (TedLawson)Tue, 18 Jul 2023 01:48:59 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/week-7-review/GSOC Week 6 Reviewhttps://blogs.python-gsoc.org/en/tedlawsons-blog/gsoc-week-6-review/<p><strong>Accomplishments:</strong><br> This week I am proud to have completed the conversion of the rest of the archiver test folder from unittest to pytest. If you will recall, two weeks ago I laid the foundation for these changes by removing the unittest based foundation `ArchiverTestBaseCase` - replacing the setup and teardown methods with pytest fixtures, and converting the rest of the methods to helper functions. My goal this week was to finish the conversion of the 38 test modules and remove all elements of unittest, replacing them with their pytest equivalents. By the end of the week I have completed the conversion of all files (over 6000 lines!) and submitted a PR for the changes that was able to pass all CI tests. Not only this, but the test suite runs slightly faster after my changes, and the code coverage has remained the same. <br> <br> <strong>Challenges:</strong><br> This week went very smooth - I had a clear objective and with the foundation complete I was able to move quickly through the test files and to convert them. The challenge I hit this week was getting the tests to pass the CI checks, as I had only ran the tests on my local Mac machine. Windows tests ran into some errors that I was not seeing before, but I was able to do some trial and error that got them to work as intended. Additionally, I hit an issue with the socket path names for a test being too long when using the pytest fixture `tmp_dir`:<br> `<br> name = tmp_path / "unix-socket"</p> <p>sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)</p> <p>&gt; sock.bind(os.path.join(name))</p> <p>E OSError: AF_UNIX path too long</p> <p>`<br> <br> I switched to using tempfile.mktemp which allowed me to set a shorter path name. This passed the test locally, however when I pushed the changes to GitHub I received a warning: <em>"Insecure temporary file. Call to deprecated function tempfile.mktemp may be insecure." </em> After doing some digging I found that mktemp files are fundamentally insecure, as they do not ensure exclusive access to a file with the temporary name they return. The file name returned by these functions is guaranteed to be unique on creation but the file must be opened in a separate operation. It was suggested to use a CM, tempfile.TemporaryDirectory, as a temporary directory. This directory was automatically cleaned up after exiting the CM, and worked as intended to pass the test and all CI checks.<br> <br> <strong>The week ahead:</strong><br> As I wrap up the Borg Unittest to Pytest conversion project, I still have a couple PR's left to get merged in. I will work with Thomas, my mentor who oversees Borg, to ensure that the PRs are buttoned up and ready to be merged. I will also prepare for my next project - increasing Vorta's code coverage - by reviewing the current code coverage, identifying areas of the code base that are lacking coverage, with a special focus on unit testing functions and methods as opposed to integration testing.</p>big.tedde@gmail.com (TedLawson)Wed, 12 Jul 2023 14:46:41 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/gsoc-week-6-review/Week 5https://blogs.python-gsoc.org/en/tedlawsons-blog/week-5-7/<p><strong>Accomplishments:</strong></p> <p>This week I continued my work on the archiver folder, and had a couple meetings with my mentor, Manu, to discuss the progress and where to go from here. I was able to complete the conversion of the ArchiverTestCaseBase to pytest by splitting it into helper functions and pytest fixtures, improving on the foundation that I had begun last week. Additionally, I was able to convert half of the tests in the archiver folder to use the new foundation, and I split up the PR's into more manageable sizes such that my other mentor, Thomas, would have an easier time looking through and reviewing the test files. </p> <p><strong>Challenges:</strong></p> <p>The biggest challenge I faced this week was deciding the best way to separate the old ArchiverTestCaseBase into helper functions and pytest fixtures. The approach Manu and I decided on was the path of least change - removing the helper functions from the unittest class but keeping them in the archiver folder `__init__` , and moving the setup and teardown functions into `conftest` as pytest fixtures. Once me and my mentor agreed on the foundation, it was easy to make progress.</p> <p><strong>The week ahead:</strong></p> <p>This week, I will finish converting the archiver folder of tests. I have 18 more test files to go, but since the foundation has been set it it just quick work to get them converted one at a time. For each test file, I am running them using the current unittest framework and recording the number of tests, how many pass or get skipped, and the execution time. I am then converting the tests to the new pytest framework and recording the same data to ensure consistency in test completion, as well as to see if there are any improvements in execution time. My goal by the end of the week is to have a completed archiver folder of tests that is all put into one PR and passes the Borg CI tests. This is a lofty goal, but I am confident I can grind it out!<br> <br> Tune in next week to see how the goals turned out! Thank you for taking the time to read my updates, and have an excellent week!</p> <p> </p>big.tedde@gmail.com (TedLawson)Wed, 05 Jul 2023 02:33:56 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/week-5-7/Week 4 - Finding my Stridehttps://blogs.python-gsoc.org/en/tedlawsons-blog/week-4-finding-my-stride/<p>Accomplishments:</p> <p>Xattr tests PR got merged this week, and the Repo tests are completed and waiting on final approval. It feels really good to have these finished up! The biggest accomplishment this week, however, was converting all of the archiver unit test base functions to pytest. These archiver unit test base functions were the groundwork for all 20 test files in the archiver folder, and by getting these converted into pytest fixtures I was able to begin quickly making inroads to the remaining test files still needing conversion to pytest. I was able to get the unit test functions converted to pytest by Tuesday, and then I was able to complete at least one test file each day this week, and even a little extra over the weekend during a long flight! It felt great to move so quickly through these files, and I feel like I am finally finding my stride and keeping to a pace that I can be proud of.</p> <p>Challenges:</p> <p>This week saw surprisingly few challenges. One issue I hit, however, was when trying to convert some helper functions from the unittest base to pytest fixtures so they could be used by all the test files. Here is an example of the function that I would need to convert:</p> <pre>def open_archive(self, name): repository = Repository(self.repository_path, exclusive=True) with repository: manifest = Manifest.load(repository, Manifest.NO_OPERATION_CHECK) archive = Archive(manifest, name) return archive, repository </pre> <p>When I originally tried to convert this to a pytest fixture, I did something like this:</p> <pre>@pytest.fixture() def open_archive(archiver): def archive_and_repository(name): repo_path = archiver.repository_path repository = Repository(repo_path, exclusive=True) with repository: manifest = Manifest.load(repository, Manifest.NO_OPERATION_CHECK) archive = Archive(manifest, name) return archive, repository return archive_and_repository</pre> <p>What I realized, however, was that these type of helper functions should not be fixtures at all. Instead, they should be functions placed in a utils module, and imported by the tests. My mentor gave me a good rule of thumb: Fixtures should only be used if there is a specific setup or teardown being preformed,  while helper functions should be instead placed in a utils package.</p> <p>The week ahead: </p> <p>This week I have a meeting with my mentor, Manu, set up for Wednesday morning. I will also be attending the GSoC contributor mid-summer evaluation meeting on Tuesday morning. Other than the two meetings, I will be continuing to work through the rest of the archiver test folder. I am working quite quickly through these and anticipate being finished with 10 of the 20 test files by the end of the week.</p> <p>Thanks to everyone for reading, and I look forward to updating on my progress again next week!</p>big.tedde@gmail.com (TedLawson)Tue, 27 Jun 2023 14:48:36 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/week-4-finding-my-stride/Week 3 - A big week of learning!https://blogs.python-gsoc.org/en/tedlawsons-blog/week-3-a-big-week-of-learning/<p>Accomplishments:</p> <p>This week I made major progress with the repository test files, and also began working on the extended attributes ('xattr') test cases. I found this past week to be very enlightening, as I began to better understand the "why" behind a lot of Pytest concepts. For example, one member of the community taught me to use the built in pytest fixture `tmp_path` for all temp directories and files, as it automatically cleans up after itself and works consistently across all OS's. I also got a better understanding of context managers, a concept that was really tripping me up in week 2. I also feel good about getting more involved with the commentary this week, as both my mentors and a community members pitched in ideas to help me with the draft PRs I've submitted. After a week of solid progress, the repository tests are pretty near completion, and the xattr tests just need a couple finishing touches. The repository tests are almost 1250 lines of code, and has been a lot of work to get to where it is today, so I feel really proud of the work that has been done there this week.</p> <p>Challenges:</p> <p>A week would not be complete without some minor setbacks, and this week I certainly had my fair share. at one point I was getting a bit demotivated with the repository tests. I was getting a lot of community feedback on how to make them better, but sometimes the feedback would conflict and I would not be sure how to proceed. With such. big file, making even a small change to one of the fixtures of context managers would take lots of time to refactor across all the tests, and this became very tedious. However, my mentor Manu gave me some really great advice: he told me to start small and just get a couple of tests working before pushing the changes for review. Only after approval should I then refactor all tests to include the changes. He called this method the 'tracer bullet' style, and it really helped improve me speed.</p> <p>The week ahead:<br> Repo and xattr tests should be finished up soon, and then I will begin working on converting the archiver folder of test. This folder has a lot of old unittest style tests, so my work is definitely cut out for me! At the end of this week I will get the ball rolling on my second project - implement profile sidebar for Vorta. I will start a FR post in the Vorta community to begin brainstorming what this could look like and thoughts on how it could be implemented. </p> <p> </p> <p>It has been an incredible week with lots of progress! Thank you all for reading, and I hope to catch you again next week!</p> <p> </p>big.tedde@gmail.com (TedLawson)Tue, 20 Jun 2023 02:50:38 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/week-3-a-big-week-of-learning/Week 2 - Test suite conversion to pytest continues!https://blogs.python-gsoc.org/en/tedlawsons-blog/week-2-test-suite-conversion-to-pytest-continues/<p>Accomplishments:</p> <p>I ended week 1 feeling a little behind in pace, so I worked though the weekend to parameterize two test files: 'item' and 'version'. These tests needed relatively small changes compared to the other files in the test suite, so I knocked them out and had a PR merged by the end of the weekend. This felt good, and led to me starting week 2 on a high note. Unfortunately, this is where my accomplishments ended, as I hit a lot of roadblocks on my next task: repository tests. Oh man, I got caught up a lot here! Lets dive in...</p> <p>Challenges:</p> <p>On the surface, the repository tests were a straight forward conversion from Unittest to Pytest. I needed to create a pytest fixture that replicated the unittest setup and teardown functions, then mimic the reopen functionality that closes a repository and reopens the same repo fresh from disk. Finally, I would translate the roughly 1,100 lines of tests to pytest. Unfortunately, things did not go to plan. I was able to get the repository fixture to work, however things went awry when I tried to reopen the repo, as I ended up nesting context managers in a way that was both ugly to read and also did not function as intended. I want to thank my mentors and the community for all the help pointing me in the right direction as I work to rewrite the tests in a way that did not nest the context managers and helped the code execute (mostly) as intended. By Friday, I had completed translating all 1,100 lines from unittest into pytest, however I am still working to ensure the repository fixture and reopen context manager works as intended.<br> <br> The Week Ahead:</p> <p>Going into week three I plan on wrapping up the repository tests and begin working on the next tests that need help: xattr, archive, and the archiver commands folder of tests. I certainly have my work cut out for me, but thanks to my supportive mentors and a wonderful community of helpers, I am confident I will continue to make solid progress.</p> <p>Thank you all for taking the time to read my blog, and I look forward to updating you again next week!<br>  </p>big.tedde@gmail.com (TedLawson)Tue, 13 Jun 2023 21:11:27 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/week-2-test-suite-conversion-to-pytest-continues/Week 1 - Coding Begins, and 1st PR Mergedhttps://blogs.python-gsoc.org/en/tedlawsons-blog/week-1-coding-begins-and-1st-pr-merged/<p><strong>Accomplishments:</strong></p> <p>As the start of the coding period commenced, I felt prepared and ready. My first GSoC project is Borg Pytest conversion, which entails converting the remaining Borg tests still using the unittest framework into the more modern and powerful pytest framework. I started with the compression tests, as this testing file had a good amount of duplicated code that could be easily reduced through the use of pytest parameterization. I started with just a couple of tests, passed the changes by my mentor, Manu, for approval Monday night, and then continued on to the rest of the test file. By Tuesday night I had a draft PR submitted for review by my other mentor, Thomas, who in turn provided valuable feedback on ways to improve my work. The refinement process took two more days, with my first PR getting merged this morning. Very exciting!<br> <br> <strong>Challenges:</strong></p> <p>I faced two main challenges this week. The first was understanding the concepts that were being tested in the compression tests. Although obvious in hindsight, I should have started by reading the Borg documentation on compression and obfuscation. This would have led to me understanding the way the tests were written better, and I could have avoided wasting my mentors time explaining information to me that I should have sought out myself. The second challenge I faced this week was time. Everything took longer than I anticipated. Although this is often the case when learning new concepts, I am concerned that I am not currently at the pace I need to be to complete this project in the 3 weeks I have allotted. To combat this, I am going to dedicate some time over the weekend to starting on the next testing files, and I also hope to get quicker with my work as the concepts become increasingly familiar to me. <br> <br> <strong>The Week Ahead:</strong></p> <p>My next test file to migrate is the repository tests. This test file is in need of pytest fixtures and parameterization. Additionally, there is room for small parameterization improvements in the 'version' and 'item' test files that could lead to some fast gains. On Wednesday of next week I have a call set up with Manu, were we will discuss current project progress and outline a timeline for getting the rest of the test files converted. <br> <br> Thank you all for reading, and I look forward to bringing another week of updates next Friday!</p>big.tedde@gmail.com (TedLawson)Fri, 02 Jun 2023 23:36:26 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/week-1-coding-begins-and-1st-pr-merged/Week 0 - May 22 to May 26https://blogs.python-gsoc.org/en/tedlawsons-blog/week-0-may-22-to-may-26/<p><b>Week 0 - Community bonding period concludes + final preparations for official start of GSoC.</b></p> <p><em>Ted Lawson </em></p> <p><i>May 26th, 2023</i></p> <p> </p> <p><strong>Overview:</strong></p> <p>This week was the final week of the community bonding period, and I used this time connect with fellow GSoC Contributors, gain a deeper familiarity with the Vorta and Borg codebases, as well as work on Vorta issues that relate to my future GSoC projects. </p> <p><strong>Community bonding:</strong></p> <p>This week was the final week of the 'community bonding' portion of GSoC. On Monday of this week I reached out to my mentor with status updates and my areas of focus for the week ahead. Throughout the week I talked with members of the community regarding my current PR's in progress for Vorta (more on that later) and obstacles I was encountering, and have stayed active in GSoC group chat communications with other program contributors. </p> <p><strong>Environment Setup: </strong></p> <p>With official coding and project work beginning next week, one area of focus for me at the beginning of this week was ensuring my development environments were ready to go. As I am working on projects for both the Borg CLI and the Vorta GUI, I forked each of these repos and got the respective environments set up locally. I hit some snags along the way, which I will discuss in the "obstacles encountered" portion of this blog.</p> <p><strong>Codebase familiarity: </strong></p> <p>An area of focus for me this week was to dive into the codebase and get more familiar with the structure of the code and how different components interacted with each other. With 2 of my 4 GSoC projects involving test coverage, it is important for me to understand what the code is doing so that I will be better equipped to help test it. </p> <p><strong>Coding: </strong></p> <p>This week, I spent the majority of my time working on my PR: &lt;bdi&gt;<a href="https://github.com/borgbase/vorta/pull/1719">Setting for new number format (work in progress)</a>. This PR aims to create a setting for users to be able to choose the way they would like archive sizes displayed in the archive tab. By default, archive sizes are displayed using dynamic units of measurement (MB, GB, etc) that best fit the archive size. However, some users prefer to have all archive sizes displayed in the same unit of measurement, so this setting will offer them the choice of that functionality. While implementing the setting, I learned about pyqt signals and how to connect a change in setting to an update of the GUI. Additionally, while writing tests for the setting I gained a deeper understanding of how to mock function calls and the utility behind these mocks. All experience I can gain with testing will translate directly into my GSoC projects - half of which involve testing as the main area of focus. &lt;/bdi&gt;</p> <p><strong>Obstacles Encountered:</strong></p> <p>As mentioned above, I ran into some issues while setting up my forked version of Borg locally on my computer. Although I was cloning the latest Borg codebase, the version info was referencing an old version of Borg that caused it not to work on my computer. When I instead cloned the official Borg repo, I did not have this issue. This was confusing, since I believed cloning the codebase should lead to identical setups. After a couple hours of troubleshooting on my own, I reached out to the community for help by starting a Github Discussion on the issue I was facing. My mentor responded, and alerted me that I probably had outdated GitHub tags, and sure enough this was the issue. When I updated the tags, everything worked and my environment was ready to go.  <br> <br> Another obstacle I encountered this week was while implementing a setting that needed to trigger a GUI update. Specifically, when the setting I create was toggled, it needed to refresh the archive tab in the GUI to display new archive size units of measurement. After asking for help on the issues page, a member of the community suggested I try connecting a pyqt signal to a change in setting that would in turn update the GUI. This was my first time using pyqt signals and I was impressed with how powerful and easy to use they were. </p> <p><strong>The Week Ahead:</strong></p> <p>Going into next week, I am prepared and excited for the official start to GSoC and the projects that lie ahead. The first project up to bat is converting the Borg testing suite from unittest to pytest. My mentor and I discussed this project in depth during our first meeting, and I will start will the so-called "low-hanging fruit". These are the tests that can easily and obviously be improved with the use of pytest fixtures and parameterization. My mentor has suggested working on small parts of code at a time (just a test or two), and running the changes by him for the first couple weeks before submitting PRs to ensure I am on the correct track. My goal next week is to go through each file in the testing suite, identify which areas could be improved, and begin work on the most obvious areas for improvement as I gain the experience and confidence to move on to the rest of the testing suite. </p> <p><strong>Conclusion:</strong></p> <p>This has been a great week of learning and preparing for the 1st project to begin - I am very excited for the official start of GSoC!! Here in Seattle the weather has turned sunny and beautiful as we transition into the summertime. I hope everyone reading this is enjoying as lovely a day as I. Stay tuned each Friday for an update on progress, and thank you for reading!</p> <p> </p>big.tedde@gmail.com (TedLawson)Fri, 26 May 2023 21:03:48 +0000https://blogs.python-gsoc.org/en/tedlawsons-blog/week-0-may-22-to-may-26/