FlightRadarAPI 1.5.0__tar.gz → 1.5.1__tar.gz

flightradarapi-1.5.1/FlightRadar24/__init__.py

@@ -0,0 +1,37 @@
+# -*- coding: utf-8 -*-
+
+"""
+Deprecated import alias for the FlightRadarAPI SDK.
+
+The package was renamed to ``FlightRadarAPI`` so the Python import name
+matches the PyPI distribution name and the Node.js package name. This
+module re-exports the public API and aliases every submodule so legacy
+imports such as ``from FlightRadar24 import FlightRadar24API`` or
+``from FlightRadar24.errors import CloudflareError`` keep working, but a
+``DeprecationWarning`` is emitted on import.
+"""
+
+import importlib
+import pkgutil
+import sys
+import warnings
+
+import FlightRadarAPI as _pkg
+
+warnings.warn(
+    "Importing from 'FlightRadar24' is deprecated and will be removed in a "
+    "future release. Import from 'FlightRadarAPI' instead "
+    "(e.g. 'from FlightRadarAPI import FlightRadar24API').",
+    DeprecationWarning,
+    stacklevel=2,
+)
+
+# Mirror every submodule of FlightRadarAPI under the legacy FlightRadar24
+# namespace so dotted imports keep resolving without touching disk.
+for _info in pkgutil.walk_packages(_pkg.__path__, prefix=f"{_pkg.__name__}."):
+    _mod = importlib.import_module(_info.name)
+    sys.modules[_info.name.replace(_pkg.__name__, __name__, 1)] = _mod
+del _info, _mod
+
+from FlightRadarAPI import *  # noqa: E402, F401, F403
+from FlightRadarAPI import __all__, __author__, __version__  # noqa: E402, F401

{flightradarapi-1.5.0/FlightRadar24 → flightradarapi-1.5.1/FlightRadarAPI}/__init__.py

@@ -12,7 +12,7 @@ https://www.flightradar24.com/terms-and-conditions
 """
 
 __author__ = "Jean Loui Bernard Silva de Jesus"
-__version__ = "1.5.0"
+__version__ = "1.5.1"
 
 from .api import FlightRadar24API
 from .core import Countries

{flightradarapi-1.5.0/FlightRadar24 → flightradarapi-1.5.1/FlightRadarAPI}/api.py

@@ -38,7 +38,7 @@ class FlightRadar24API:
         :param max_workers: Maximum threads used when fetching flight details concurrently
         :param impersonate: TLS impersonation profile (curl_cffi). Override when FR24
             updates its Cloudflare bot mitigation faster than this library releases.
-            See ``FlightRadar24.request.DEFAULT_IMPERSONATE`` for the current default.
+            See ``FlightRadarAPI.request.DEFAULT_IMPERSONATE`` for the current default.
         :param retry: Optional :class:`RetryPolicy` applied to transient failures
             (``CloudflareError`` and curl_cffi network errors). Defaults to no retry.
         """
@@ -230,30 +230,39 @@ class FlightRadar24API:
         lon = math.radians(longitude)
 
         approx_earth_radius = 6371
+
+        # Distance from the centre to a corner of the bounding square.
         hypotenuse_distance = math.sqrt(2 * (math.pow(half_side_in_km, 2)))
 
+        # The two diagonal bearings (in radians) used below are 225° (SW corner,
+        # yields the min lat/lon) and 45° (NE corner, yields the max lat/lon).
+        bearing_sw = math.radians(225)
+        bearing_ne = math.radians(45)
+
+        # Destination-point formula along the SW bearing → south-west corner.
         lat_min = math.asin(
             math.sin(lat) * math.cos(hypotenuse_distance / approx_earth_radius)
             + math.cos(lat)
             * math.sin(hypotenuse_distance / approx_earth_radius)
-            * math.cos(225 * (math.pi / 180)),
+            * math.cos(bearing_sw),
         )
         lon_min = lon + math.atan2(
-            math.sin(225 * (math.pi / 180))
+            math.sin(bearing_sw)
             * math.sin(hypotenuse_distance / approx_earth_radius)
             * math.cos(lat),
             math.cos(hypotenuse_distance / approx_earth_radius)
             - math.sin(lat) * math.sin(lat_min),
         )
 
+        # Same formula along the NE bearing → north-east corner.
         lat_max = math.asin(
             math.sin(lat) * math.cos(hypotenuse_distance / approx_earth_radius)
             + math.cos(lat)
             * math.sin(hypotenuse_distance / approx_earth_radius)
-            * math.cos(45 * (math.pi / 180)),
+            * math.cos(bearing_ne),
         )
         lon_max = lon + math.atan2(
-            math.sin(45 * (math.pi / 180))
+            math.sin(bearing_ne)
             * math.sin(hypotenuse_distance / approx_earth_radius)
             * math.cos(lat),
             math.cos(hypotenuse_distance / approx_earth_radius)
@@ -276,7 +285,8 @@ class FlightRadar24API:
 
         :param country: Country name
         """
-        flag_url = Core.country_flag_url.format(country.lower().replace(" ", "-"))
+        slug = country.lower().replace(" ", "-")
+        flag_url = Core.country_flag_url.format(slug)
         headers = Core.image_headers.copy()
 
         headers.pop("origin", None)  # Does not work for this request.

{flightradarapi-1.5.0/FlightRadar24 → flightradarapi-1.5.1/FlightRadarAPI}/request.py

@@ -76,7 +76,7 @@ def _run_with_retry(fn, retry: Optional[RetryPolicy]):
 
 class APIClient:
     """
-    Central HTTP client for the FlightRadar24 package.
+    Central HTTP client for the FlightRadarAPI package.
 
     Owns the persistent session (cookie jar, TLS fingerprint, future bypass logic)
     so that the rest of the codebase never has to deal with those concerns directly.

{flightradarapi-1.5.0 → flightradarapi-1.5.1}/Makefile

@@ -1,20 +1,41 @@
 # Makefile for FlightRadarAPI Python package
 
 # Variables
-PACKAGE_NAME = FlightRadar24
-PYTHON = python3
-PIP = pip3
+PACKAGE_NAME = FlightRadarAPI
 BUILD_DIR = build
 DIST_DIR = dist
 EGG_INFO = $(PACKAGE_NAME).egg-info
 VENV_DIR = venv
 TEST_DIR = tests
 
+# Minimum offline coverage required by `test-coverage` and by the CI workflow.
+# Keep this single source-of-truth in sync with `.github/workflows/python-package.yml`
+# (raise both together when the offline suite grows).
+COVERAGE_MIN = 60
+
+# Dev tooling installed by `install-dev` / `dev-setup` on top of `.[tests]`.
+# Centralised so the two targets do not drift.
+DEV_TOOLS = pytest-cov flake8 black mypy twine build hatch pip-audit
+
+# Auto-detect virtualenv. When `venv/` already exists, every target uses its
+# interpreter so `make test` / `make lint` / etc. work without first running
+# `source venv/bin/activate`. Otherwise we fall back to the system python.
+#
+# Targets that *create* the venv (notably `dev-setup`) must call
+# `$(VENV_DIR)/bin/pip` directly — variable expansion happens at parse time,
+# so the auto-detection below cannot pick up a venv created later in the
+# same `make` invocation.
+ifneq ($(wildcard $(VENV_DIR)/bin/python),)
+PYTHON := $(VENV_DIR)/bin/python
+PIP := $(VENV_DIR)/bin/pip
+else
+PYTHON := python3
+PIP := pip3
+endif
+
 # Colors for output
 GREEN = \033[0;32m
 YELLOW = \033[0;33m
-RED = \033[0;31m
-BLUE = \033[0;34m
 NC = \033[0m # No Color
 
 # Default target
@@ -43,47 +64,49 @@ help:
 	@echo "  $(YELLOW)check-deps$(NC)       - Check for outdated dependencies"
 	@echo "  $(YELLOW)update-deps$(NC)      - Update dependencies"
 	@echo "  $(YELLOW)security$(NC)         - Run security audit"
-	@echo "  $(YELLOW)docs$(NC)             - Generate documentation"
+	@echo "  $(YELLOW)docs$(NC)             - Build the MkDocs site (output in ../site/)"
+	@echo "  $(YELLOW)docs-serve$(NC)       - Serve the MkDocs site locally with auto-reload"
 	@echo "  $(YELLOW)venv$(NC)             - Create virtual environment"
-	@echo "  $(YELLOW)venv-activate$(NC)    - Show command to activate venv"
 	@echo "  $(YELLOW)all$(NC)              - Run full pipeline (install, lint, test, build)"
 
-# Create virtual environment
+# Create virtual environment.
+#
+# Uses `python3` literally rather than `$(PYTHON)`: when this target runs with
+# an existing venv on disk the auto-detection at the top would point at
+# `venv/bin/python` and we'd be asking the venv to recreate itself, which is
+# both confusing and unreliable on Python builds with restricted `venv`
+# support. The system python3 is the right bootstrap interpreter.
 .PHONY: venv
 venv:
 	@echo "$(GREEN)Creating virtual environment...$(NC)"
-	$(PYTHON) -m venv $(VENV_DIR)
+	python3 -m venv $(VENV_DIR)
 	@echo "$(GREEN)Virtual environment created in $(VENV_DIR)$(NC)"
 	@echo "$(YELLOW)To activate: source $(VENV_DIR)/bin/activate$(NC)"
 
-# Show activation command
-.PHONY: venv-activate
-venv-activate:
-	@echo "$(YELLOW)To activate virtual environment run:$(NC)"
-	@echo "source $(VENV_DIR)/bin/activate"
+# Install package in editable mode (no dev tools).
+.PHONY: install
+install:
+	@echo "$(GREEN)Installing package in editable mode...$(NC)"
+	$(PIP) install -e .
+	@echo "$(GREEN)Package installed successfully!$(NC)"
 
-# Install dependencies
+# Backwards-compatible alias for `install`. Kept so older docs / muscle memory
+# referencing `make install-deps` keep working; consolidating eliminated the
+# old redundant double `pip install -e .` between `install-deps` and `install`.
 .PHONY: install-deps
-install-deps:
-	@echo "$(GREEN)Installing dependencies...$(NC)"
-	$(PIP) install -e .
-	@echo "$(GREEN)Dependencies installed successfully!$(NC)"
+install-deps: install
 
-# Install development dependencies
+# Install everything needed for development: package (editable) + test extras
+# + the tooling used by other Makefile targets (lint, type-check, security,
+# build). Dev tools are defined once in `$(DEV_TOOLS)` so this target and
+# `dev-setup` cannot drift.
 .PHONY: install-dev
 install-dev:
 	@echo "$(GREEN)Installing development dependencies...$(NC)"
 	$(PIP) install -e ".[tests]"
-	$(PIP) install pytest-cov flake8 black mypy twine build hatch
+	$(PIP) install $(DEV_TOOLS)
 	@echo "$(GREEN)Development dependencies installed successfully!$(NC)"
 
-# Install package in development mode
-.PHONY: install
-install: install-deps
-	@echo "$(GREEN)Installing package in development mode...$(NC)"
-	$(PIP) install -e .
-	@echo "$(GREEN)Package installed successfully!$(NC)"
-
 # Run tests
 .PHONY: test
 test:
@@ -98,11 +121,12 @@ test-verbose:
 	$(PYTHON) -m pytest $(TEST_DIR) -v -s
 	@echo "$(GREEN)Verbose tests completed!$(NC)"
 
-# Run tests with coverage
+# Run tests with coverage. Threshold lives in $(COVERAGE_MIN) so it stays in
+# sync with the CI workflow — bump both together.
 .PHONY: test-coverage
 test-coverage:
-	@echo "$(GREEN)Running tests with coverage...$(NC)"
-	$(PYTHON) -m pytest $(TEST_DIR) --cov=$(PACKAGE_NAME) --cov-report=html --cov-report=term
+	@echo "$(GREEN)Running tests with coverage (min $(COVERAGE_MIN)%)...$(NC)"
+	$(PYTHON) -m pytest $(TEST_DIR) --cov=$(PACKAGE_NAME) --cov-report=html --cov-report=term --cov-fail-under=$(COVERAGE_MIN)
 	@echo "$(GREEN)Coverage report generated!$(NC)"
 	@echo "$(YELLOW)HTML report available at htmlcov/index.html$(NC)"
 
@@ -127,41 +151,43 @@ type-check:
 	$(PYTHON) -m mypy $(PACKAGE_NAME) --ignore-missing-imports
 	@echo "$(GREEN)Type checking completed!$(NC)"
 
-# Clean build artifacts
-.PHONY: clean
-clean:
+# Clean *build* artifacts only. Kept narrow so that `build` (and everything
+# that depends on it: `validate`, `publish`, `release`) does not silently
+# wipe coverage reports or pytest/mypy caches that the developer just ran.
+.PHONY: clean-build
+clean-build:
 	@echo "$(GREEN)Cleaning build artifacts...$(NC)"
-	rm -rf $(BUILD_DIR)
-	rm -rf $(DIST_DIR)
-	rm -rf $(EGG_INFO)
-	rm -rf .pytest_cache
-	rm -rf htmlcov
-	rm -rf .coverage
-	rm -rf .mypy_cache
+	rm -rf $(BUILD_DIR) $(DIST_DIR) $(EGG_INFO)
+
+# Full clean: build artifacts + caches + coverage reports. Use this between
+# branches or before publishing. Note that `build` no longer depends on
+# `clean` — call `make clean build` if you want a fully scrubbed build.
+.PHONY: clean
+clean: clean-build
+	@echo "$(GREEN)Cleaning caches and coverage reports...$(NC)"
+	rm -rf .pytest_cache htmlcov .coverage .mypy_cache
 	find . -type d -name "__pycache__" -exec rm -rf {} +
-	find . -type f -name "*.pyc" -delete
-	find . -type f -name "*.pyo" -delete
-	find . -type f -name "*.pyd" -delete
-	find . -type f -name ".coverage" -delete
+	find . -type f \( -name "*.pyc" -o -name "*.pyo" -o -name "*.pyd" \) -delete
 	@echo "$(GREEN)Cleanup completed!$(NC)"
 
-# Build package
+# Build package. Depends on `clean-build` (not `clean`) so coverage / cache
+# files survive — see the comment on `clean-build` for motivation.
 .PHONY: build
-build: clean
+build: clean-build
 	@echo "$(GREEN)Building package...$(NC)"
 	$(PYTHON) -m build
 	@echo "$(GREEN)Package built successfully!$(NC)"
 
 # Build wheel package only
 .PHONY: build-wheel
-build-wheel: clean
+build-wheel: clean-build
 	@echo "$(GREEN)Building wheel package...$(NC)"
 	$(PYTHON) -m build --wheel
 	@echo "$(GREEN)Wheel package built successfully!$(NC)"
 
 # Build source distribution only
 .PHONY: build-sdist
-build-sdist: clean
+build-sdist: clean-build
 	@echo "$(GREEN)Building source distribution...$(NC)"
 	$(PYTHON) -m build --sdist
 	@echo "$(GREEN)Source distribution built successfully!$(NC)"
@@ -200,43 +226,65 @@ check-deps:
 	@echo "$(GREEN)Checking for outdated dependencies...$(NC)"
 	$(PIP) list --outdated
 
-# Update dependencies
+# Update every dependency that `install-dev` installs — the package itself
+# (editable, with test extras) AND the dev tools. Updating only the extras
+# (the previous behaviour) silently drifted flake8/mypy/etc. behind.
 .PHONY: update-deps
 update-deps:
 	@echo "$(GREEN)Updating dependencies...$(NC)"
 	$(PIP) install --upgrade -e ".[tests]"
+	$(PIP) install --upgrade $(DEV_TOOLS)
 	@echo "$(GREEN)Dependencies updated!$(NC)"
 
-# Security audit
+# Security audit. Uses `pip-audit` to match the CI workflow (the older
+# `safety` CLI was retired upstream and is no longer the recommended tool).
+# Assumes `make install-dev` already installed `pip-audit`.
 .PHONY: security
 security:
-	@echo "$(GREEN)Running security audit...$(NC)"
-	$(PIP) install safety
-	safety check
+	@echo "$(GREEN)Running security audit (pip-audit)...$(NC)"
+	$(PYTHON) -m pip_audit
 	@echo "$(GREEN)Security audit completed!$(NC)"
 
-# Generate documentation
+# Build the MkDocs site. The configuration (`mkdocs.yml`) and the `docs/`
+# directory live in the repository root, so we invoke MkDocs from one level
+# up. Requires `mkdocs-material` (install with `pip install mkdocs-material`
+# — kept out of `install-dev` because the docs site is rebuilt by CI, not
+# every developer needs the dependency locally).
 .PHONY: docs
 docs:
-	@echo "$(GREEN)Generating documentation...$(NC)"
-	@if [ -d "docs" ]; then \
-		cd docs && make html; \
-		echo "$(GREEN)Documentation generated in docs/_build/html/$(NC)"; \
-	else \
-		echo "$(YELLOW)No docs directory found. Skipping documentation generation.$(NC)"; \
-	fi
-
-# Full development pipeline
+	@echo "$(GREEN)Building MkDocs site...$(NC)"
+	cd .. && mkdocs build
+	@echo "$(GREEN)Site generated in ../site/$(NC)"
+
+# Serve the MkDocs site locally with auto-reload.
+.PHONY: docs-serve
+docs-serve:
+	@echo "$(GREEN)Serving MkDocs site at http://127.0.0.1:8000 ...$(NC)"
+	cd .. && mkdocs serve
+
+# Full development pipeline. Uses `install-dev` (not `install`) so that
+# `lint`, `type-check`, and `test` have flake8 / mypy / pytest available
+# when this is run from a fresh checkout.
 .PHONY: all
-all: install lint type-check test build validate
+all: install-dev lint type-check test build validate
 	@echo "$(GREEN)Full pipeline completed successfully!$(NC)"
 
-# Development workflow targets
+# Development workflow target.
+#
+# Installs every dev dependency *into the venv* using `$(VENV_DIR)/bin/pip`
+# directly — do not rely on `$(PIP)` here, because Make resolves variables at
+# parse time and the venv may not have existed yet when this Makefile was
+# read.
 .PHONY: dev-setup
-dev-setup: venv install-dev install
+dev-setup: venv
+	@echo "$(GREEN)Installing project (editable) + dev dependencies into $(VENV_DIR)/...$(NC)"
+	$(VENV_DIR)/bin/pip install --upgrade pip
+	$(VENV_DIR)/bin/pip install -e ".[tests]"
+	$(VENV_DIR)/bin/pip install $(DEV_TOOLS)
 	@echo "$(GREEN)Development environment setup completed!$(NC)"
-	@echo "$(YELLOW)Don't forget to activate the virtual environment:$(NC)"
-	@echo "source $(VENV_DIR)/bin/activate"
+	@echo ""
+	@echo "$(YELLOW)You can now run targets directly — they auto-detect $(VENV_DIR)/.$(NC)"
+	@echo "$(YELLOW)To activate the venv in your shell anyway:$(NC) source $(VENV_DIR)/bin/activate"
 
 .PHONY: pre-commit
 pre-commit: lint type-check test
@@ -246,12 +294,16 @@ pre-commit: lint type-check test
 pre-publish: all security
 	@echo "$(GREEN)Pre-publish checks completed!$(NC)"
 
-# CI/CD targets
+# CI/CD target. `install-dev` already installs the package in editable mode
+# via `pip install -e ".[tests]"`, so a separate `install` step would be
+# redundant.
 .PHONY: ci
-ci: install-dev install lint type-check test build validate
+ci: install-dev lint type-check test build validate
 	@echo "$(GREEN)CI pipeline completed!$(NC)"
 
-# Show package info
+# Show package info. The grep filter lists every tool in $(DEV_TOOLS) plus
+# the package itself and `pytest` (installed via the `[tests]` extra). Keep
+# the regex in sync if $(DEV_TOOLS) changes.
 .PHONY: info
 info:
 	@echo "$(GREEN)Package Information:$(NC)"
@@ -261,7 +313,7 @@ info:
 	@echo "Pip: $(shell $(PIP) --version)"
 	@echo ""
 	@echo "$(GREEN)Installed packages:$(NC)"
-	@$(PIP) list | grep -E "($(PACKAGE_NAME)|pytest|flake8|black|mypy|twine|build)"
+	@$(PIP) list | grep -E "($(PACKAGE_NAME)|pytest|pytest-cov|flake8|black|mypy|twine|build|hatch|pip-audit)"
 
 # Quick release workflow
 .PHONY: release

{flightradarapi-1.5.0 → flightradarapi-1.5.1}/PKG-INFO

@@ -1,12 +1,12 @@
 Metadata-Version: 2.4
 Name: FlightRadarAPI
-Version: 1.5.0
+Version: 1.5.1
 Summary: SDK for FlightRadar24
 Project-URL: Homepage, https://github.com/JeanExtreme002/FlightRadarAPI
 Project-URL: Source Code, https://github.com/JeanExtreme002/FlightRadarAPI
 Project-URL: Documentation, https://jeanextreme002.github.io/FlightRadarAPI/
 Project-URL: Bug Reports, https://github.com/JeanExtreme002/FlightRadarAPI/issues
-Author-email: Jean Loui Bernard Silva de Jesus <jeanextreme002@gmail.com>
+Author-email: Jean Loui Bernard Silva de Jesus <contact@jeanloui.dev>
 License-Expression: MIT
 License-File: LICENSE
 Keywords: aircraft,airlines,airports,api,aviation,flightradar24,flights,radar
@@ -47,7 +47,7 @@ $ pip install FlightRadarAPI
 ## Basic Usage:
 Import the class `FlightRadar24API` and create an instance of it.
 ```py
-from FlightRadar24 import FlightRadar24API
+from FlightRadarAPI import FlightRadar24API
 fr_api = FlightRadar24API()
 ```
 

{flightradarapi-1.5.0 → flightradarapi-1.5.1}/README.md

@@ -21,7 +21,7 @@ $ pip install FlightRadarAPI
 ## Basic Usage:
 Import the class `FlightRadar24API` and create an instance of it.
 ```py
-from FlightRadar24 import FlightRadar24API
+from FlightRadarAPI import FlightRadar24API
 fr_api = FlightRadar24API()
 ```
 

{flightradarapi-1.5.0 → flightradarapi-1.5.1}/pyproject.toml

@@ -3,7 +3,7 @@ name = "FlightRadarAPI"
 dynamic = ["version"]
 description = "SDK for FlightRadar24"
 authors = [
-    { name = "Jean Loui Bernard Silva de Jesus", email = "jeanextreme002@gmail.com" },
+    { name = "Jean Loui Bernard Silva de Jesus", email = "contact@jeanloui.dev" },
 ]
 license = "MIT"
 readme = "README.md"
@@ -27,7 +27,12 @@ dependencies = [
 exclude = ["tests", ".flake8"]
 
 [tool.hatch.build.targets.wheel]
-packages = ["FlightRadar24"]
+packages = ["FlightRadarAPI", "FlightRadar24"]
+
+# Force-include the PEP 561 marker so downstream type checkers always see it,
+# regardless of future changes to the global exclude list above.
+[tool.hatch.build.targets.wheel.force-include]
+"FlightRadarAPI/py.typed" = "FlightRadarAPI/py.typed"
 
 [project.optional-dependencies]
 tests = [
@@ -41,7 +46,7 @@ tests = [
 "Bug Reports" = "https://github.com/JeanExtreme002/FlightRadarAPI/issues"
 
 [tool.hatch.version]
-path = "FlightRadar24/__init__.py"
+path = "FlightRadarAPI/__init__.py"
 
 [tool.pytest.ini_options]
 testpaths = ["tests"]