Skip to main content

CLI Reference

The tif1 CLI provides a powerful, feature-rich, and production-ready command-line interface for exploring Formula 1 data directly from your terminal. Built with Typer for robust argument parsing and Rich for beautiful, colorful terminal output with tables and progress indicators, the CLI brings the full power of tif1 to your command line with zero configuration required.

What is the tif1 CLI?

The tif1 CLI is a comprehensive command-line tool that provides instant access to Formula 1 data without writing a single line of Python code. It’s designed for data analysts, F1 enthusiasts, developers, and anyone who wants to explore F1 data quickly and efficiently from their terminal. Key Features:
  • Zero Configuration: Works out of the box after installation
  • Rich Terminal Output: Beautiful tables with color-coded data and Unicode borders
  • Intelligent Caching: Automatic caching with SQLite for blazing-fast repeated queries
  • Progress Indicators: Real-time feedback during data loading operations
  • Comprehensive Error Handling: Clear, actionable error messages
  • Cross-Platform: Works on Linux, macOS, and Windows
  • Scriptable: Perfect for automation, CI/CD pipelines, and shell scripts
  • Performance Optimized: Built for speed with efficient data processing
  • Flexible Output: Pipe-friendly output for integration with Unix tools

Overview

The CLI is designed for multiple use cases and user personas:

Use Cases

  1. Quick Data Exploration
    • Instantly view race calendars, session schedules, driver lineups, and lap times
    • No Python code required - just type and see results
    • Perfect for quick lookups and ad-hoc queries
    • Ideal for exploring data structure before writing analysis code
  2. Debugging & Development
    • Test data availability and verify API responses
    • Troubleshoot issues with comprehensive debug logging
    • Validate data integrity and completeness
    • Identify network issues, cache problems, or data inconsistencies
  3. Cache Management
    • Monitor cache size, location, and performance metrics
    • Clear cache when needed to free disk space
    • Verify cache behavior and hit rates
    • Optimize storage usage for large-scale analysis
  4. Scripting & Automation
    • Integrate F1 data into shell scripts and automation workflows
    • Build CI/CD pipelines that depend on F1 data
    • Create scheduled jobs for data collection and analysis
    • Automate repetitive data extraction tasks
  5. Learning & Discovery
    • Explore the data structure and available information
    • Understand F1 data hierarchy (seasons → events → sessions → drivers)
    • Learn event naming conventions and session types
    • Discover what data is available before committing to analysis
  6. Performance Analysis
    • Compare lap times across sessions and drivers
    • Track driver performance throughout a race weekend
    • Analyze qualifying vs race pace
    • Identify performance trends and patterns
  7. Data Validation
    • Verify data completeness for specific events
    • Check driver participation in sessions
    • Validate lap counts and timing data
    • Ensure data quality before analysis

Who Should Use the CLI?

  • Data Analysts: Quick data exploration and validation
  • F1 Enthusiasts: Instant access to race data and statistics
  • Developers: Testing and debugging data pipelines
  • DevOps Engineers: Automation and monitoring scripts
  • Researchers: Data collection for academic studies
  • Journalists: Quick fact-checking and statistics lookup
  • Content Creators: Gathering data for articles, videos, or social media

Performance Characteristics

The CLI is optimized for speed and efficiency:
  • First Request: 2-10 seconds (network fetch + cache write)
  • Cached Requests: <1 second (local SQLite read)
  • Cache Benefit: 5-10x faster for repeated queries
  • Memory Efficient: Streams data without loading entire datasets
  • Network Optimized: Uses CDN for fast global access
  • Concurrent Safe: Multiple CLI instances can run simultaneously

Installation

The CLI is automatically included when you install tif1. No additional dependencies, configuration files, or setup steps are required - it just works out of the box.

Standard Installation

Install tif1 using pip (Python 3.10 or higher required):
After installation, the tif1 command will be available globally in your terminal. The CLI uses the same Python environment as your tif1 installation, ensuring consistency between CLI and programmatic usage.

Installation Methods

1. System-Wide Installation (requires admin/sudo):
2. User Installation (recommended for non-admin users):
3. Virtual Environment (recommended for development):
4. Development Installation (from source):

Verify Installation

Confirm the CLI is installed correctly and check the version:
Expected output:
If the command is not found, troubleshoot using these steps:
  1. Check Python Environment:
  2. Verify PATH Configuration:
  3. Locate tif1 Executable:
  4. Common Issues:
    • Virtual environment not activated: Run source venv/bin/activate (Linux/macOS) or venv\Scripts\activate (Windows)
    • User installation PATH issue: Add ~/.local/bin (Linux/macOS) or %APPDATA%\Python\Scripts (Windows) to PATH
    • Permission issues: Use pip install --user tif1 instead of system-wide installation

Upgrading

To upgrade to the latest version:

Uninstallation

To remove tif1:

Getting Started

Your First Commands

Let’s walk through a complete workflow from discovering events to analyzing lap times: Step 1: Discover Available Events Start by listing all events in a season to see what data is available:
This shows all Grand Prix events for 2025. Note the exact event names - you’ll need them for subsequent commands. Step 2: Check Event Sessions Pick an event and see what sessions are available:
This displays all sessions (Practice 1-3, Qualifying, Race) for Monaco. Note that sprint weekends have different session structures. Step 3: View Participating Drivers See which drivers participated in a specific session:
This loads the session data and displays all drivers with their teams. The first time you run this, it will fetch data from the network (2-10 seconds). Subsequent runs will be much faster thanks to caching. Step 4: Analyze Lap Times View fastest lap times for all drivers:
Or check a specific driver’s fastest lap:
Step 5: Manage Cache Check your cache size and location:
Clear cache if needed:

Understanding the Data Hierarchy

F1 data in tif1 follows a clear hierarchy:
Example Navigation:

Common Patterns

Pattern 1: Weekend Analysis
Pattern 2: Driver Tracking
Pattern 3: Multi-Event Comparison
Pattern 4: Historical Analysis

Quick Reference Card


Quick Start

Get started with these common commands:

Global Usage Pattern

All commands follow a consistent, predictable pattern:
  • COMMAND: The action to perform (e.g., events, sessions, drivers, fastest)
  • ARGUMENTS: Required positional arguments in a specific order (e.g., year, event name, session name)
  • OPTIONS: Optional flags that modify behavior (e.g., --driver, --yes, -d)

Command Structure

Commands are organized hierarchically by data granularity:
  1. Season Level: events - Lists all events in a season
  2. Event Level: sessions - Lists all sessions in an event
  3. Session Level: drivers, fastest - Analyzes data within a session
  4. Utility Commands: cache-info, cache-clear, version, debug - Management and debugging

Getting Help

Every command has built-in help documentation:
The help output shows:
  • Command description and purpose
  • Required arguments with types
  • Optional flags and their defaults
  • Usage examples

Command Naming Conventions

  • Commands use lowercase with hyphens for multi-word names (e.g., cache-info, cache-clear)
  • Arguments use natural language names (e.g., year, event, session)
  • Options use double dashes for long form (--driver) and single dash for short form (-d)

Core Concepts

Understanding these core concepts will help you use the CLI effectively and avoid common pitfalls.

Event Names

Event names are the official Grand Prix names as they appear in the FIA Formula 1 World Championship calendar. They must match exactly - the CLI performs case-sensitive string matching. Standard Event Name Format: Most events follow the pattern: "[Location] Grand Prix" Examples:
  • “Monaco Grand Prix”
  • “British Grand Prix”
  • “Italian Grand Prix”
  • “Japanese Grand Prix”
  • “Australian Grand Prix”
Special Event Names: Some events have unique naming conventions:
  • “São Paulo Grand Prix” (note the special character ã)
  • “United States Grand Prix” (not “US Grand Prix”)
  • “Emilia Romagna Grand Prix” (not “Imola Grand Prix”)
  • “Mexico City Grand Prix” (not “Mexican Grand Prix”)
  • “Las Vegas Grand Prix” (not “Vegas Grand Prix”)
  • “Saudi Arabian Grand Prix” (not “Saudi Grand Prix”)
Why Exact Names Matter: The CLI uses these names to construct CDN URLs and cache keys. Even small differences will cause lookup failures:
Shell Quoting Rules: Always use quotes around event names with spaces. The shell interprets unquoted spaces as argument separators:
Finding Exact Event Names: Always use the events command to get the exact event names:
Copy-Paste Workflow: The safest approach is to copy event names directly from the events output:

Session Names

Session names identify specific track sessions within an event. Like event names, they must match exactly and are case-sensitive. Standard Weekend Format: Traditional race weekends have 5 sessions:
  1. “Practice 1” (Friday morning)
  2. “Practice 2” (Friday afternoon)
  3. “Practice 3” (Saturday morning)
  4. “Qualifying” (Saturday afternoon)
  5. “Race” (Sunday)
Sprint Weekend Format: Sprint weekends have a different structure:
  1. “Practice 1” (Friday)
  2. “Sprint Qualifying” (Saturday morning)
  3. “Sprint” (Saturday afternoon)
  4. “Qualifying” (Saturday evening)
  5. “Race” (Sunday)
Session Name Variations:
  • Practice sessions: “Practice 1”, “Practice 2”, “Practice 3” (note the space)
  • Qualifying: “Qualifying” (not “Quali” or “Q”)
  • Sprint qualifying: “Sprint Qualifying” (two words)
  • Sprint race: “Sprint” (not “Sprint Race”)
  • Main race: “Race” (not “Grand Prix” or “Main Race”)
Common Mistakes:
Discovering Available Sessions: Always use the sessions command to see what sessions are available for an event:
Sprint Weekend Detection: To check if an event is a sprint weekend:

Driver Codes

Drivers are identified by standardized three-letter codes assigned by the FIA. These codes are unique and persistent throughout a driver’s career. Code Format:
  • Always 3 letters (uppercase)
  • Usually derived from driver’s surname
  • Unique across all active drivers
  • Case-insensitive in CLI (VER = ver = Ver)
Common Driver Codes (2025): Finding Driver Codes: Use the drivers command to see all driver codes for a session:
Using Driver Codes: Driver codes are used with the --driver option:
Historical Driver Codes: Driver codes can change between seasons if a driver switches teams or if there’s a code conflict:
Reserve and Substitute Drivers: Occasionally, reserve or substitute drivers participate:

Data Loading & Caching

The CLI implements intelligent caching to optimize performance and reduce network requests. Cache Architecture:
First Request (Cache Miss): When you request data for the first time:
  1. Cache Lookup: CLI checks local SQLite cache
  2. Network Fetch: Data is downloaded from CDN (jsdelivr)
  3. JSON Parsing: Raw JSON is parsed into structured data
  4. DataFrame Creation: Data is converted to pandas/polars DataFrame
  5. Cache Write: Processed data is stored in cache
  6. Return: Data is displayed to user
Timing breakdown:
  • Network fetch: 200-2000ms (depends on connection speed)
  • JSON parsing: 50-200ms (depends on data size)
  • DataFrame creation: 20-100ms
  • Cache write: 50-150ms
  • Total: 2-10 seconds
Subsequent Requests (Cache Hit): When you request the same data again:
  1. Cache Lookup: CLI checks local SQLite cache
  2. Cache Read: Data is loaded from disk
  3. Deserialization: Cached data is reconstructed
  4. Return: Data is displayed to user
Timing breakdown:
  • Cache read: 10-50ms
  • Total: < 1 second
Performance Benefit: Cache provides 5-10x speedup for repeated queries:
Cache Location: Cache location is platform-specific: Custom Cache Location: Override the default cache location:
Cache Persistence:
  • Cache persists across CLI sessions
  • Cache survives system reboots
  • Cache is shared across all CLI commands
  • Cache is NOT shared with Python API (separate cache)
Cache Invalidation: Cache entries never expire automatically. To force fresh data:
Cache Size Management: Monitor cache growth:
Cache Behavior:
  • Each session is cached independently
  • Different data types (laps, telemetry) are cached separately
  • Cache keys include year, event, session, and data type
  • Cache is SQLite-based (ACID compliant, crash-safe)
Disabling Cache: For testing or debugging, disable caching:

Output Formatting

The CLI uses Rich library for beautiful, colorful terminal output with professional formatting. Table Components:
  1. Title: Event name, year, and session
  2. Headers: Column names with color coding
  3. Borders: Unicode box-drawing characters
  4. Data Rows: Color-coded values
  5. Summary: Total counts and metadata
Color Scheme:
  • Cyan: Numeric indices, driver codes
  • Green: Event names, team names, success messages
  • Yellow: Driver codes in results, warnings
  • Magenta: Timing data, lap times
  • Red: Error messages, failures
  • Bold: Emphasis, headers, totals
Table Example:
Progress Indicators: Long-running operations show progress:
Terminal Compatibility:
  • Unicode Support: Uses Unicode box-drawing characters
  • Color Support: Automatically detects terminal color capabilities
  • Width Adaptation: Tables adapt to terminal width
  • Fallback: Gracefully degrades on limited terminals
Piping Behavior: When output is piped, formatting is preserved:
Plain Text Extraction: Remove formatting for parsing:
Accessibility:
  • Screen reader compatible (plain text fallback)
  • High contrast colors for visibility
  • Clear visual hierarchy
  • Consistent formatting across commands

Error Handling & Troubleshooting

The CLI provides clear, actionable error messages to help you quickly identify and resolve issues.

Common Error Messages

1. Event Not Found
Cause: Event name doesn’t match exactly Solution: Use tif1 events 2025 to find the exact event name 2. Session Not Found
Cause: Session name doesn’t match exactly Solution: Use tif1 sessions 2025 "Monaco Grand Prix" to find exact session names 3. Driver Not Found
Cause: Invalid driver code or driver didn’t participate Solution: Use tif1 drivers 2025 "Monaco Grand Prix" "Race" to see available drivers 4. Network Timeout
Cause: Slow network connection or CDN unavailable Solution:
  • Check internet connection
  • Increase timeout: TIF1_TIMEOUT=60 tif1 fastest ...
  • Try again later
5. Cache Error
Cause: Insufficient permissions for cache directory Solution:
  • Fix permissions: chmod 755 ~/.cache/tif1
  • Use custom cache dir: export TIF1_CACHE_DIR=/tmp/tif1_cache
6. Data Not Available
Cause: Event hasn’t occurred yet or data not published Solution: Check if event has taken place and data is available

Troubleshooting Workflow

Step 1: Verify Command Syntax
Step 2: Verify Event and Session Names
Step 3: Use Debug Mode
Step 4: Check Cache
Step 5: Verify Network

Platform-Specific Issues

Linux:
  • Permission denied: sudo chown -R $USER ~/.cache/tif1
  • Command not found: Add ~/.local/bin to PATH
  • Encoding issues: Set export LANG=en_US.UTF-8
macOS:
  • Command not found: Ensure Python bin directory in PATH
  • Permission denied: Check SIP (System Integrity Protection) settings
  • Special characters: Use UTF-8 terminal encoding
Windows:
  • Command not found: Add Python Scripts directory to PATH
  • PowerShell execution policy: Set-ExecutionPolicy RemoteSigned
  • Path with spaces: Use quotes: "C:\Program Files\Python\Scripts\tif1"

Debug Mode

Enable verbose logging for troubleshooting:

Getting Help

Built-in Help:
Community Support:

Platform-Specific Guidance

Linux

Installation:
Cache Location:
Shell Integration:
Performance Tips:

macOS

Installation:
Cache Location:
Terminal Recommendations:
  • iTerm2: Best Unicode and color support
  • Terminal.app: Good default support
  • Alacritty: Fast, GPU-accelerated
Shell Integration:

Windows

Installation:
Cache Location:
PowerShell Usage:
Command Prompt (CMD) Usage:
Windows Terminal Recommendations:
  • Windows Terminal: Best modern option (Unicode, colors, tabs)
  • PowerShell 7: Improved over PowerShell 5.1
  • Git Bash: Unix-like experience on Windows
Common Windows Issues:
  1. Execution Policy Error:
  2. Path with Spaces:
  3. Unicode Characters:

Commands

events - List Season Events

Display all Formula 1 events (races) for a specific season year. Syntax:
Arguments: Description: The events command retrieves and displays the complete race calendar for a given season. This includes all Grand Prix events scheduled for that year, displayed in chronological order with their official event names. The data is sourced from tif1’s embedded schedule data, which includes historical seasons from 2018 onwards and current/future seasons as they become available. Output Format: The command displays a formatted table with:
  • #: Sequential event number (1-based index)
  • Event: Official event name (e.g., “Monaco Grand Prix”, “British Grand Prix”)
  • Total count: Summary line showing total number of events
Examples:
Sample Output:
Use Cases:
  • Quick reference for race calendar
  • Planning data analysis for specific events
  • Verifying event names for use in other commands
  • Checking season length and schedule
Notes:
  • Event names must match exactly when used in other commands (case-sensitive)
  • Use quotes around event names with spaces in subsequent commands
  • The command works offline if schedule data is embedded in the package

sessions - List Event Sessions

Display all sessions available for a specific Formula 1 event. Syntax:
Arguments: Description: The sessions command retrieves all practice, qualifying, sprint, and race sessions for a specific Grand Prix event. Different events may have different session structures (e.g., sprint weekends have different formats). Typical session types include:
  • Practice 1, 2, 3: Free practice sessions (FP1, FP2, FP3)
  • Qualifying: Qualifying session
  • Sprint Qualifying: Sprint qualifying (on sprint weekends)
  • Sprint: Sprint race (on sprint weekends)
  • Race: Main Grand Prix race
Output Format: The command displays a formatted table with:
  • #: Sequential session number
  • Session: Official session name
  • Title: Event name and year
Examples:
Sample Output:
Sample Output (Sprint Weekend):
Use Cases:
  • Verify available sessions before loading data
  • Check session naming conventions
  • Understand event format (standard vs sprint weekend)
  • Plan analysis workflow
Important Notes:
  • Event names are case-sensitive and must match exactly
  • Always use quotes around event names with spaces
  • Session names must be used exactly as shown in subsequent commands
  • Not all events have the same session structure
Common Errors:

drivers - List Session Drivers

Display all drivers who participated in a specific session, along with their team information. Syntax:
Arguments: Description: The drivers command loads session data and displays all drivers who participated, along with their team affiliations. This is useful for verifying driver availability, checking team rosters, and getting driver codes for use in other commands. The command shows a progress indicator while loading session data from the network or cache. Output Format: The command displays a formatted table with:
  • Driver: Three-letter driver code (e.g., VER, HAM, LEC)
  • Team: Full team name (e.g., Red Bull Racing, Mercedes, Ferrari)
  • Total count: Summary line showing total number of drivers
Examples:
Sample Output:
Use Cases:
  • Get driver codes for use with --driver option in other commands
  • Verify which drivers participated in a session
  • Check team lineups for a specific event
  • Identify reserve or substitute drivers
  • Confirm driver availability before detailed analysis
Performance Notes:
  • First run requires network fetch (shows progress indicator)
  • Subsequent runs use cached data (much faster)
  • Loading time depends on session data size and network speed
  • Typical load time: 1-5 seconds (first run), <1 second (cached)
Important Notes:
  • Driver codes are standardized three-letter abbreviations (e.g., VER, HAM, LEC)
  • Team names reflect the official team name at the time of the event
  • Not all drivers may have complete data in all sessions (e.g., DNS, DNF)
  • Use exact driver codes from this output in subsequent commands
Common Patterns:

fastest - Show Fastest Laps

Display fastest lap times for all drivers or a specific driver in a session. Syntax:
Arguments: Options: Description: The fastest command analyzes lap data to find and display the fastest lap times achieved during a session. This is particularly useful for qualifying analysis, race pace comparison, and performance evaluation. Behavior:
  • Without --driver: Shows fastest lap for each driver, sorted by lap time (fastest first)
  • With --driver: Shows only the specified driver’s fastest lap with detailed timing
The command loads complete session data including all laps, then processes to find the fastest valid lap for each driver. Output Format: All Drivers Mode (default):
  • Pos: Position in fastest lap ranking (1 = fastest)
  • Driver: Three-letter driver code
  • Team: Team name
  • Time: Lap time in seconds (formatted to 3 decimal places)
Single Driver Mode (--driver specified):
  • Simple text output showing driver code and fastest lap time
Examples:
Sample Output (All Drivers):
Sample Output (Single Driver):
Use Cases:
  • Qualifying Analysis: Compare driver performance in qualifying sessions
  • Race Pace: Identify fastest race laps for pace analysis
  • Driver Comparison: Quickly compare lap times between drivers
  • Performance Tracking: Monitor driver/team performance across sessions
  • Quick Checks: Verify specific driver’s best performance
Performance Notes:
  • Loads complete lap data for the session (may take 2-10 seconds first time)
  • Cached data makes subsequent runs much faster (<1 second)
  • Processing time increases with number of laps in session
  • Qualifying sessions are typically faster to load than races
Data Considerations:
  • Only includes valid, completed laps (excludes in/out laps, invalid laps)
  • Times are shown in seconds with millisecond precision
  • Deleted lap times (track limits violations) may be excluded
  • Some drivers may not have valid laps (DNS, early DNF)
Important Notes:
  • Driver codes must match exactly (case-sensitive: VER, not ver)
  • Invalid driver codes will result in an error message
  • Times are sorted automatically (fastest first)
  • The --driver option is useful for quick single-driver checks
Common Patterns:
Error Handling:

cache-info - Display Cache Statistics

Show detailed information about the tif1 cache, including location, size, and file count. Syntax:
Arguments: None Description: The cache-info command provides a summary of your local tif1 cache, which stores downloaded F1 data to speed up subsequent requests. This is useful for monitoring cache growth, troubleshooting storage issues, and understanding cache behavior. Output Format: The command displays:
  • Cache location: Full filesystem path to the cache directory
  • Cache files: Number of cache-related files
  • Total size: Combined size of all cache files in megabytes (MB)
Examples:
Sample Output (Linux/macOS):
Sample Output (Windows):
Sample Output (macOS):
Use Cases:
  • Monitor cache growth: Check how much disk space the cache is using
  • Troubleshoot performance: Verify cache is being used
  • Storage management: Identify if cache needs clearing
  • Debugging: Confirm cache location for manual inspection
  • Documentation: Record cache paths for team documentation
Cache Location by Platform: Cache Structure: The cache directory typically contains:
  • cache.sqlite: Main SQLite database file
  • cache.sqlite-wal: Write-Ahead Log file (WAL mode)
  • cache.sqlite-shm: Shared memory file (WAL mode)
Understanding Cache Size: Cache size grows based on:
  • Number of sessions loaded: Each session adds lap data, telemetry, etc.
  • Data types requested: Telemetry data is larger than lap times
  • Historical data: Older seasons accumulate over time
  • Typical sizes:
    • Fresh install: ~0 MB
    • Light usage (few sessions): 50-200 MB
    • Moderate usage (multiple seasons): 200-500 MB
    • Heavy usage (extensive analysis): 500+ MB
Performance Impact:
  • Cache hit: Data loads in <1 second (from disk)
  • Cache miss: Data loads in 2-10 seconds (from network)
  • Cache benefit: 5-10x faster load times for cached data
Custom Cache Location: You can override the default cache location using the TIF1_CACHE_DIR environment variable:
Troubleshooting: If cache size seems incorrect:
  1. Check for multiple cache locations (environment variable override)
  2. Verify disk space availability
  3. Check file permissions on cache directory
  4. Consider clearing cache if corrupted: tif1 cache-clear
Related Commands:
  • tif1 cache-clear: Clear all cached data
  • Environment variable TIF1_CACHE_DIR: Override cache location
  • Environment variable TIF1_ENABLE_CACHE: Disable caching entirely

cache-clear - Clear Cache Database

Delete all cached data to free up disk space or force fresh data fetches. Syntax:
Options: Description: The cache-clear command removes all cached Formula 1 data from your local cache database. This is useful when:
  • Freeing disk space: Cache has grown too large
  • Forcing fresh data: Suspect cached data is stale or corrupted
  • Troubleshooting: Debugging cache-related issues
  • Testing: Measuring cold-start performance
  • Data updates: Ensuring you get the latest data from the CDN
Important: Clearing the cache means all subsequent data requests will need to fetch from the network, which will be slower until the cache is rebuilt. Interactive Mode (default): By default, the command asks for confirmation before clearing:
Sample Output:
If you answer ‘n’ or press Enter (default is No):
Non-Interactive Mode (--yes flag): Skip the confirmation prompt for scripting or automation:
Sample Output:
Short Form:
Use Cases:
  1. Disk Space Management:
  2. Force Data Refresh:
  3. Automated Scripts:
  4. Troubleshooting:
What Gets Cleared: The command deletes:
  • All cached session data (laps, telemetry, weather, messages)
  • All cached schedule data
  • All cached driver information
  • SQLite database tables (structure is preserved, data is removed)
What Doesn’t Get Cleared:
  • Cache directory itself (remains for future use)
  • Configuration files (.tif1rc)
  • Log files (if any)
Performance Impact: After clearing cache:
  • First data load: 2-10 seconds (network fetch)
  • Subsequent loads: <1 second (cached)
  • Cache rebuild: Automatic as you use commands
Safety Notes:
  • No data loss: Only cached data is removed; original data remains on CDN
  • Reversible: Cache rebuilds automatically as you use the CLI
  • No configuration changes: Your settings remain intact
  • Safe to interrupt: Can be cancelled with Ctrl+C before confirmation
Exit Codes:
  • 0: Cache cleared successfully
  • 1: Error during cache clearing (permissions, disk issues, etc.)
  • 130: User cancelled with Ctrl+C
Related Commands:
  • tif1 cache-info: Check cache size before clearing
  • Environment variable TIF1_CACHE_DIR: Custom cache location
  • Environment variable TIF1_ENABLE_CACHE: Disable caching entirely

version - Show Version Information

Display the installed tif1 version number. Syntax:
Arguments: None Description: The version command displays the currently installed version of tif1. This is useful for:
  • Troubleshooting: Verify which version you’re running when reporting issues
  • Compatibility: Check if you have the required version for specific features
  • Updates: Confirm successful upgrade after running pip install --upgrade tif1
  • Documentation: Ensure documentation matches your installed version
Examples:
Sample Output:
Output Format: The output follows the pattern: tif1 version X.Y.Z Where:
  • X: Major version (breaking changes)
  • Y: Minor version (new features, backwards compatible)
  • Z: Patch version (bug fixes, backwards compatible)
Use Cases:
  1. Check Current Version:
  2. Verify Upgrade:
  3. Bug Reports:
  4. Scripting:
Version History:
  • 0.2.0: Current release with CLI improvements
  • 0.1.0: Initial release
Checking for Updates: To check if a newer version is available:
To upgrade to the latest version:
Exit Codes:
  • 0: Success (always succeeds)

debug - Debug Session Loading

Load a session with detailed debug logging enabled to troubleshoot issues. Syntax:
Arguments: Description: The debug command loads a session with verbose debug logging enabled, providing detailed information about the data loading process. This is invaluable for:
  • Troubleshooting: Diagnose why data isn’t loading correctly
  • Performance Analysis: See timing for each loading step
  • Network Issues: Identify connection problems or timeouts
  • Cache Behavior: Verify cache hits/misses
  • Development: Understand internal data flow
Unlike normal commands that show minimal output, debug displays:
  • HTTP requests and responses
  • Cache lookups and stores
  • Data parsing steps
  • Error details and stack traces
  • Timing information
  • Internal state changes
Examples:
Sample Output:
Sample Output (Cache Hit):
Use Cases:
  1. Diagnose Loading Failures:
  2. Performance Investigation:
  3. Cache Verification:
  4. Network Troubleshooting:
Debug Output Details: The debug output includes:
  • [DEBUG] prefix: All debug messages
  • Timestamps: Relative timing for operations
  • URLs: Full CDN URLs being fetched
  • File sizes: Data size being downloaded/parsed
  • Cache operations: Hit/miss, read/write timing
  • DataFrame info: Row counts, column names
  • Errors: Full stack traces for failures
Performance Metrics: Typical timing breakdown:
  • Cache hit: 10-50ms total
  • Cache miss:
    • HTTP fetch: 200-2000ms (depends on network)
    • JSON parsing: 50-200ms (depends on data size)
    • DataFrame creation: 20-100ms
    • Cache write: 50-150ms
    • Total: 2-10 seconds
Logging Levels: The debug command sets logging to DEBUG level, which shows:
  • DEBUG: Detailed internal operations
  • INFO: General information messages
  • WARNING: Potential issues
  • ERROR: Failures and exceptions
Output Destination: Debug output goes to:
  • stdout: Normal output (session loaded message)
  • stderr: Debug logging (all [DEBUG] messages)
This allows separating debug info from actual data:
Comparison with Normal Commands: Important Notes:
  • Debug logging adds ~5-10% overhead due to logging operations
  • Output can be verbose (hundreds of lines for large sessions)
  • Sensitive data (URLs, file paths) may be logged
  • Not recommended for production scripts (use normal commands)
Exit Codes:
  • 0: Session loaded successfully
  • 1: Error loading session (network, data, cache issues)
Related Commands:
  • tif1 drivers: Normal driver listing (no debug output)
  • tif1 fastest: Normal fastest lap listing (no debug output)
  • Environment variable TIF1_LOG_LEVEL: Set logging level globally

Common Workflows

Explore Available Data

Start with high-level exploration and drill down to specific details:
This workflow helps you:
  • Discover available data without guessing event/session names
  • Verify data exists before writing Python code
  • Understand the data structure and hierarchy

Quick Performance Analysis

Compare driver performance across sessions:

Driver-Specific Analysis

Focus on a single driver’s performance:

Cache Management Workflow

Monitor and maintain cache health:

Troubleshooting Workflow

Diagnose and fix data loading issues:

Historical Data Analysis

Explore data from past seasons:

Sprint Weekend Analysis

Sprint weekends have different session structures:

Scripting & Automation

Integrate CLI into shell scripts:
Usage:

Data Validation Workflow

Verify data completeness and accuracy:

Batch Processing

Process multiple events efficiently:

Advanced Usage

Piping & Text Processing

Combine CLI with standard Unix tools:

Output Redirection

Save CLI output to files:

Environment Variable Usage

Customize CLI behavior with environment variables:

Conditional Execution

Use exit codes for conditional logic:

Parallel Processing

Run multiple CLI commands in parallel:

JSON Output (Future Enhancement)

While not currently supported, you can parse table output:

Tips & Best Practices

General Tips

  1. Always use quotes for multi-word names:
  2. Use tab completion (if your shell supports it):
  3. Check help when unsure:
  4. Verify event names first:
  5. Use short options for speed:

Performance Tips

  1. Let cache warm up:
  2. Monitor cache size:
  3. Use specific driver queries:
  4. Avoid unnecessary debug mode:

Scripting Tips

  1. Handle errors gracefully:
  2. Use variables for reusability:
  3. Suppress output when needed:
  4. Check exit codes:

Troubleshooting Tips

  1. Start with debug mode:
  2. Clear cache when in doubt:
  3. Check version compatibility:
  4. Verify network connectivity:
  5. Use offline mode for testing:

Data Quality Tips

  1. Verify driver count:
  2. Check for missing data:
  3. Compare across sessions:
  4. Use historical data for validation:

Exit Codes

  • 0: Success
  • 1: General error (network, data not found, etc.)
  • 2: Invalid arguments

Environment Variables

The CLI respects the same environment variables as the Python API for consistent behavior across interfaces:

Available Environment Variables

Usage Examples

Custom Cache Directory:
Use Polars Backend:
Disable Caching:
Increase Timeout:
Adjust Retry Behavior:
Enable Debug Logging:
Offline Mode:

Configuration File

While the CLI primarily uses environment variables, you can create a shell configuration file for persistent settings: Linux/macOS (~/.tif1rc):
Windows PowerShell ($PROFILE):

Environment Variable Precedence

When multiple configuration sources exist, precedence is:
  1. Command-line override (highest priority)
  2. Shell environment variable
  3. Configuration file
  4. Default value (lowest priority)

Advanced Topics

Performance Optimization

1. Parallel Processing Process multiple sessions simultaneously:
2. Cache Warming Pre-populate cache for faster subsequent access:
3. Selective Data Loading Only load data you need:
4. Batch Processing Process multiple events efficiently:

Integration with Other Tools

1. jq (JSON Processing) While CLI doesn’t output JSON directly, you can convert:
2. awk (Text Processing)
3. gnuplot (Visualization)
4. Database Import

CI/CD Integration

GitHub Actions Example:
GitLab CI Example:
Jenkins Pipeline Example:

Docker Integration

Dockerfile:
Usage:

Monitoring and Logging

1. Command Logging Track all CLI usage:
2. Performance Monitoring Measure command execution time:
3. Error Tracking Capture and log errors:

Security Considerations

1. Cache Security Protect cached data:
2. Network Security Use secure connections:
3. Input Validation Sanitize user input in scripts:

Testing and Validation

1. Smoke Tests Verify CLI functionality:
2. Data Validation Verify data integrity:
3. Regression Testing Compare outputs across versions:

Best Practices

General Best Practices

  1. Always Quote Multi-Word Arguments
  2. Use Exact Names from CLI Output
  3. Check Help When Unsure
  4. Use Short Options for Speed
  5. Leverage Tab Completion

Performance Best Practices

  1. Let Cache Warm Up
  2. Monitor Cache Size
  3. Use Specific Queries
  4. Avoid Unnecessary Debug Mode

Scripting Best Practices

  1. Handle Errors Gracefully
  2. Use Variables for Reusability
  3. Suppress Output When Needed
  4. Check Exit Codes
  5. Use Functions for Repeated Tasks

Data Quality Best Practices

  1. Verify Driver Count
  2. Check for Missing Data
  3. Compare Across Sessions
  4. Use Historical Data for Validation

Security Best Practices

  1. Validate User Input
  2. Use Secure Cache Locations
  3. Be Cautious with Piping

Maintenance Best Practices

  1. Keep tif1 Updated
  2. Monitor Cache Growth
  3. Clean Up Old Data
  4. Document Your Workflows

Frequently Asked Questions (FAQ)

General Questions

Q: Is the CLI free to use? A: Yes, tif1 CLI is completely free and open-source. Q: Do I need an API key? A: No, tif1 CLI doesn’t require any API keys or authentication. Q: What data is available? A: Historical F1 data from 2018 onwards, including lap times, telemetry, weather, and race control messages. Q: How often is data updated? A: Data is typically available within hours after each session concludes. Q: Can I use this for commercial purposes? A: Check the license terms, but generally yes for analysis and research.

Technical Questions

Q: Why is the first command slow? A: The first request fetches data from the network and caches it. Subsequent requests are much faster. Q: How much disk space does the cache use? A: Typically 50-500 MB depending on usage. Check with tif1 cache-info. Q: Can I use this offline? A: Yes, if data is already cached. Use TIF1_OFFLINE_MODE=true to prevent network requests. Q: Does the CLI support Python 2? A: No, Python 3.10 or higher is required. Q: Can I run multiple CLI instances simultaneously? A: Yes, the cache is designed to handle concurrent access safely.

Data Questions

Q: Why is driver X missing from the results? A: The driver may not have participated in that session (DNS, DNF, or reserve driver). Q: Why are lap times different from official timing? A: Data source and processing may differ slightly from official FIA timing. Q: Can I get telemetry data via CLI? A: Currently, the CLI focuses on lap times and driver info. Use the Python API for telemetry. Q: How accurate is the data? A: Data is sourced from official timing systems and is generally very accurate.

Troubleshooting Questions

Q: Command not found error? A: Ensure tif1 is installed and Python Scripts directory is in your PATH. Q: Permission denied error? A: Check cache directory permissions or use a custom cache location. Q: Network timeout error? A: Increase timeout with TIF1_TIMEOUT=60 or check your internet connection. Q: Cache corruption error? A: Clear cache with tif1 cache-clear -y and try again.

Changelog

Version 0.2.0 (Current)

New Features:
  • Added debug command for verbose logging
  • Improved error messages with actionable suggestions
  • Enhanced table formatting with Rich library
  • Added progress indicators for long operations
Improvements:
  • Faster cache lookups with optimized SQLite queries
  • Better Unicode support for special characters in event names
  • Improved Windows compatibility
Bug Fixes:
  • Fixed cache corruption on interrupted downloads
  • Fixed driver code case sensitivity issues
  • Fixed table rendering on narrow terminals

Version 0.1.0 (Initial Release)

Features:
  • Basic CLI commands: events, sessions, drivers, fastest
  • SQLite-based caching system
  • Rich terminal output with tables
  • Cross-platform support (Linux, macOS, Windows)

Contributing

We welcome contributions to improve the CLI! Here’s how you can help:

Reporting Issues

  1. Check existing issues on GitHub
  2. Provide detailed error messages and steps to reproduce
  3. Include your OS, Python version, and tif1 version
  4. Use tif1 debug output when relevant

Suggesting Features

  1. Open a GitHub issue with the “enhancement” label
  2. Describe the use case and expected behavior
  3. Provide examples of how the feature would be used

Contributing Code

  1. Fork the repository
  2. Create a feature branch
  3. Make your changes with tests
  4. Submit a pull request

Documentation

Help improve this documentation:
  • Fix typos and clarify confusing sections
  • Add more examples and use cases
  • Translate to other languages

License

tif1 CLI is released under the MIT License. See LICENSE file for details.

Support


Acknowledgments

  • Typer: CLI framework
  • Rich: Terminal formatting
  • pandas/polars: Data processing
  • niquests: HTTP client
  • TracingInsights: Data source

Last updated: April 2026 CLI Version: 0.2.0 Documentation Version: 2.0
Last modified on May 8, 2026