Refactor for more modular codebase

[egrace479]

This also reveals other refactoring opportunities that can be handled other issues such as:

• verification module (e.g. verify_downloads)
• image processing module (e.g. downsample_and_save)
• validation module (e.g. validate_csv_extension)

Originally posted by @thompsonmj in #36 (review)

[thompsonmj]

That sounds good to me, preserving a per-row/image unit of work, since that’s what will make concurrency easier later.
With handoffs basically staying like they are:
row in input -> download result -> image-processing (if needed) -> logs

The refactor should preserve that flow, but make the handoffs more explicit so later changes are safer. In particular, it would help if a row became a planned work item, and download returned a structured result with enough metadata for future retry/concurrency work.

That is, each input row should be normalized into a small object/dict containing the decisions needed to process that image.
For example, planning a row could resolve:

• row index / source row metadata
• URL
• output filename
• output path
• extension
• optional downsample output path
• whether it should be skipped because output already exists

Then the downloader/worker receives that planned item instead of repeatedly reinterpreting the raw CSV row.

The main point is that planning should answer “what should happen for this row?” and the worker should answer “what happened when we tried it?”

Considering these in light of a cautious concurrency issue coming soon. And this can makes concurrency easier later because the scheduler can queue WorkItems without needing to know about CSV columns, filename inference, ...

And yeah, verification can wait until sum-buddy changes take shape.

Should prepare for #55

[codedbyishika]

Proposal for Refraction

File Structure and Functions

├── src/
│ └── cautiousrobot/
│ ├── about.py
│ ├── init.py
│ ├── main.py
│ ├── validate_csv_extension.py # CSV validation
│ ├── downsample_and_save.py # Image processing
│ ├── verify_downloads.py # Checksum
│ ├── buddy_check.py # Existing buddy check class
│ ├── utils.py
│ └── exceptions.py

Process and Explanation

• Create pull requests for each refraction independently
• Implement each python script changes sequentially
  The above structure is to preserve the current flow while creating explicit classes and functions and concurrency ready for future implementation.

validation.py: CSV validation [all from main.py]

• validate_csv_extension
• validate_filename_uniqueness
• handle_missing_filenames
• setup_expected_columns

downsample_and_save.py: Image processing [all from utils.py]

• downsample_and_save_image

verify_downloads.py: Checksum [all from main.py]

• process_checksums
• verify_downloads

[egrace479]

I think this looks good (noting: compute_checksums refers to process_checksums).

I'd suggest starting with the validation function extraction. Keep in mind that unittests will need to be modified as well.