feat: Activity dataclass
#87
Conversation
and ci: dependency group instead of optional dependency for linting
WalkthroughThis pull request introduces enhancements to the project's data handling and utility functions, focusing on activity tracking and dependency management. The changes include adding a new Changes
Sequence DiagramsequenceDiagram
participant Client
participant Activity
participant HTTPClient
Client->>Activity: list() or get(id)
alt list activities
Activity->>HTTPClient: Fetch activities
HTTPClient-->>Activity: Return activity data
Activity->>Activity: Sort activities
else get specific activity
Activity->>HTTPClient: Fetch activity by ID
HTTPClient-->>Activity: Return activity details
Activity->>Activity: Process and convert data
end
Activity-->>Client: Return Activity instance(s)
This sequence diagram illustrates the high-level interaction for retrieving activity data, showing how the Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (5)
Makefile(1 hunks)garth/data/__init__.py(1 hunks)garth/data/activity.py(1 hunks)garth/utils.py(1 hunks)pyproject.toml(1 hunks)
🔇 Additional comments (7)
garth/data/__init__.py (2)
1-1: Add 'Activity' to the module's public API
This change looks good and aligns with making the Activity class a first-class exported entity.
3-3: Importing Activity
No apparent issues, and consistency with the updated __all__ is maintained.
garth/utils.py (1)
36-43: Check for consistent suffix handling
The function correctly handles both "_dto" and "DTO" suffixes. The logic appears straightforward, and no issues are found with the slicing.
garth/data/activity.py (4)
9-13: Ensure consistent type usage
ActivityType is a minimal, frozen dataclass that correctly represents activity metadata. If you anticipate changes (e.g., additional fields), ensure future expansions remain consistent with Activity.
72-80: Check optional fields
The optional cadence/steps attributes help track running metrics. Ensure that downstream usage handles None values gracefully to avoid potential TypeErrors.
82-91: Revisit offset approach
The _get_localized_datetime method calculates the local offset and applies it to the GMT timestamp. Watch out for edge cases like daylight saving time transitions or historical offsets outside standard rules.
92-97: Exposing activity_start
This property elegantly exposes a localized start time. It provides clarity and ensures consistent usage with _get_localized_datetime.
| [dependency-groups] | ||
| linting = [ | ||
| "mypy>=1.13.0", | ||
| "ruff>=0.8.2", | ||
| "types-requests>=2.32.0.20241016", | ||
| ] |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider consolidating dependency management approach
The new [dependency-groups] section introduces duplicate definitions for linting dependencies that are already defined in [project.optional-dependencies]. This could lead to:
- Version conflicts if different constraints are specified
- Maintenance overhead from managing dependencies in two places
- Confusion about which dependencies are being used
Consider one of these approaches:
- Remove the duplicate definitions and use only
[dependency-groups]:
-[project.optional-dependencies]
-linting = [
- "ruff",
- "mypy",
- "types-requests",
-]
[dependency-groups]
linting = [
"mypy>=1.13.0",
"ruff>=0.8.2",
"types-requests>=2.32.0.20241016",
]- Or, keep using
[project.optional-dependencies]but with the specific versions:
[project.optional-dependencies]
linting = [
- "ruff",
- "mypy",
- "types-requests",
+ "mypy>=1.13.0",
+ "ruff>=0.8.2",
+ "types-requests>=2.32.0.20241016",
]
-[dependency-groups]
-linting = [
- "mypy>=1.13.0",
- "ruff>=0.8.2",
- "types-requests>=2.32.0.20241016",
-]Committable suggestion skipped: line range outside the PR's diff.
There was a problem hiding this comment.
@juvilius what's the advantage of this vs the current approach?
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
| uv run ruff format --check $(sources) | ||
| uv run ruff check $(sources) | ||
| uv run mypy $(sources) | ||
| uv run --group linting mypy $(sources) |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Ensure consistent usage of dependency groups
The lint target uses the new --group linting flag for mypy but not for ruff commands. This inconsistency could lead to confusion about how dependencies are managed.
Consider updating all linting commands to use the same approach:
.PHONY: lint ## Lint python source files
lint: .uv
- uv run ruff format --check $(sources)
- uv run ruff check $(sources)
- uv run --group linting mypy $(sources)
+ uv run --group linting ruff format --check $(sources)
+ uv run --group linting ruff check $(sources)
+ uv run --group linting mypy $(sources)Also, the install target needs to be updated to match the new dependency management approach:
.PHONY: install
install: .uv .pre-commit
- uv pip install -e ".[dev,linting,testing]"
+ uv pip install -e ".[dev,testing]" --group lintingCommittable suggestion skipped: line range outside the PR's diff.
|
@juvilius I apologize for not getting around to reviewing earlier. do you want to rebase, add tests and submit the changes? adding this endpoint makes sense, especially to make available in |
|
Hi, @juvilius, |
|
Hi @matin, sorry for the holdup. Let me explain. Long story short, I don't know how to easily collect every possible field for all types of |
3 participants
and ci: dependency group instead of optional dependency for linting
I've had some troubles pleasing mypy, so please check if I've made a mistake before considering to merge. :)
Also: your
Dataclass is focused on there being one of "it" per day. I'm not sure how to best reconcile it with activities.Summary by CodeRabbit
New Features
Activityclass to data module, enabling retrieval and management of activity informationChores
Refactor