Skip to content

Deprecation Warnings #6256

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
harvey0100 wants to merge 1 commit into
base: master
Choose a base branch
from
+43 −2
Open

Deprecation Warnings #6256

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions .github/workflows/autils_migration_announcement.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,12 +6,17 @@ on:
- opened
paths:
- '**/ar.py'
- '**/path.py'
- '**/astring.py'
- '**/data_structures.py'
- '**/network/ports.py'
- '**/external/gdbmi_parser.py'
- '**/external/spark.py'
- '**/gdb.py'
- '**/network/ports.py'
- '**/output.py'
- '**/path.py'
- '**/process.py'
- '**/script.py'
- '**/wait.py'

jobs:
commnet-to-pr:
Expand Down
6 changes: 6 additions & 0 deletions avocado/utils/ar.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -119,3 +119,9 @@ def read_member(self, identifier):
open_file.seek(member.offset)
return open_file.read(member.size)
return None


# pylint: disable=wrong-import-position
from avocado.utils.deprecation import log_deprecation

log_deprecation.warning("ar")
Comment on lines +124 to +127
Copy link

@gemini-code-assist gemini-code-assist bot Dec 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Using a custom log_deprecation object with a bottom-of-file import for deprecation warnings is a possible pattern, but it deviates from standard Python practices. The built-in warnings module is the idiomatic way to handle deprecations.

Using warnings.warn() would:

  • Adhere to PEP 8 by allowing the import to be at the top of the file.
  • Provide users with standard mechanisms to filter or handle these warnings (e.g., via warnings.simplefilter or the -W command-line option).
  • Avoid the need for a custom implementation and a flush() call.

Consider replacing this with a standard DeprecationWarning at the top of the module. For example:

# at the top of avocado/utils/ar.py
import warnings

warnings.warn(
    "The 'ar' utility is deprecated. It has been moved to the AAutils "
    "project and will be removed after the next LTS release. For more "
    "information, please see: https://github.com/avocado-framework/aautils",
    DeprecationWarning,
    stacklevel=2
)

If the custom log_deprecation is required for project-specific logging aggregation, please disregard this suggestion.

References
  1. PEP 8 recommends that imports should be at the top of the file. The current implementation places the import at the end of the file, which is a deviation from this standard. (link)

6 changes: 6 additions & 0 deletions avocado/utils/astring.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -508,3 +508,9 @@ def to_text(data, encoding=ENCODING, errors="strict"):
if not isinstance(data, str):
return str(data)
return data


# pylint: disable=wrong-import-position
from avocado.utils.deprecation import log_deprecation

log_deprecation.warning("astring")
Comment on lines +513 to +516
Copy link

@gemini-code-assist gemini-code-assist bot Dec 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Using a custom log_deprecation object with a bottom-of-file import for deprecation warnings is a possible pattern, but it deviates from standard Python practices. The built-in warnings module is the idiomatic way to handle deprecations.

Using warnings.warn() would:

  • Adhere to PEP 8 by allowing the import to be at the top of the file.
  • Provide users with standard mechanisms to filter or handle these warnings (e.g., via warnings.simplefilter or the -W command-line option).
  • Avoid the need for a custom implementation and a flush() call.

Consider replacing this with a standard DeprecationWarning at the top of the module. For example:

# at the top of avocado/utils/astring.py
import warnings

warnings.warn(
    "The 'astring' utility is deprecated. It has been moved to the AAutils "
    "project and will be removed after the next LTS release. For more "
    "information, please see: https://github.com/avocado-framework/aautils",
    DeprecationWarning,
    stacklevel=2
)

If the custom log_deprecation is required for project-specific logging aggregation, please disregard this suggestion.

References
  1. PEP 8 recommends that imports should be at the top of the file. The current implementation places the import at the end of the file, which is a deviation from this standard. (link)

6 changes: 6 additions & 0 deletions avocado/utils/gdb.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -894,3 +894,9 @@ def connect(self):

if self._extended_mode:
self.set_extended_mode()


# pylint: disable=wrong-import-position
from avocado.utils.deprecation import log_deprecation

log_deprecation.warning("gdb")
Comment on lines +899 to +902
Copy link

@gemini-code-assist gemini-code-assist bot Dec 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Using a custom log_deprecation object with a bottom-of-file import for deprecation warnings is a possible pattern, but it deviates from standard Python practices. The built-in warnings module is the idiomatic way to handle deprecations.

Using warnings.warn() would:

  • Adhere to PEP 8 by allowing the import to be at the top of the file.
  • Provide users with standard mechanisms to filter or handle these warnings (e.g., via warnings.simplefilter or the -W command-line option).
  • Avoid the need for a custom implementation and a flush() call.

Consider replacing this with a standard DeprecationWarning at the top of the module. For example:

# at the top of avocado/utils/gdb.py
import warnings

warnings.warn(
    "The 'gdb' utility is deprecated. It has been moved to the AAutils "
    "project and will be removed after the next LTS release. For more "
    "information, please see: https://github.com/avocado-framework/aautils",
    DeprecationWarning,
    stacklevel=2
)

If the custom log_deprecation is required for project-specific logging aggregation, please disregard this suggestion.

References
  1. PEP 8 recommends that imports should be at the top of the file. The current implementation places the import at the end of the file, which is a deviation from this standard. (link)

Comment on lines +899 to +902
Copy link

@coderabbitai coderabbitai bot Jan 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Verify the deprecation warning implementation and check if warnings are actually emitted

echo "=== Checking log_deprecation implementation ==="
if [ -f avocado/utils/deprecation.py ]; then
  cat avocado/utils/deprecation.py
else
  echo "File not found: avocado/utils/deprecation.py"
fi

echo -e "\n=== Searching for log_deprecation usage patterns ==="
rg -n "log_deprecation" --type=py -A 3 -B 1 | head -100

echo -e "\n=== Searching for deprecation warnings module imports ==="
rg -n "import warnings" --type=py | head -20

Repository: avocado-framework/avocado

Length of output: 6415

🏁 Script executed:

#!/bin/bash
echo "=== Searching for all flush() calls ==="
rg -n "\.flush\(\)" --type=py -B 2 -A 2

echo -e "\n=== Checking if there are tests for deprecation warnings ==="
fd -t f -n "*test*deprecation*" --type f
rg -n "log_deprecation\|LogDeprecation" -t py test

Repository: avocado-framework/avocado

Length of output: 8482

🏁 Script executed:

#!/bin/bash
echo "=== Finding all log_deprecation.flush() calls ==="
rg "log_deprecation\.flush" --type=py -B 5 -A 5

echo -e "\n=== Checking where/when log_deprecation warnings would be emitted ==="
rg "log_deprecation" --type=py | grep -E "(flush|warning)" | head -40

echo -e "\n=== Checking if there are integration tests that verify deprecation warnings ==="
fd test -type f | xargs rg "deprecation" -l 2>/dev/null | head -10

Repository: avocado-framework/avocado

Length of output: 2610

🏁 Script executed:

#!/bin/bash
echo "=== Checking for tests related to deprecation ==="
find . -type f -name "*.py" -path "*test*" | xargs rg "log_deprecation\|LogDeprecation" 2>/dev/null

echo -e "\n=== Checking when flush would be called during test execution ==="
rg "flush" avocado/plugins/runners/avocado_instrumented.py -B 10 -A 10

echo -e "\n=== Checking if any CLI or main entry points call flush ==="
rg "log_deprecation" avocado/core --type=py
rg "log_deprecation" avocado/plugins --type=py

echo -e "\n=== Checking documentation or release notes ==="
grep -r "log_deprecation\|LogDeprecation" docs/ 2>/dev/null || echo "No documentation found"

Repository: avocado-framework/avocado

Length of output: 1227

🏁 Script executed:

#!/bin/bash
echo "=== Checking logging configuration and where LOGGER output goes ==="
rg "LOGGER\s*=\s*logging.getLogger" avocado/utils/deprecation.py -A 5

echo -e "\n=== Checking if LOGGER.info is sufficient for warnings or if it should be LOGGER.warning ==="
rg "LOGGER\.(warning|warn)" avocado/utils/deprecation.py

echo -e "\n=== Checking logging setup in test execution ==="
rg "logging.basicConfig\|StreamHandler" avocado/core --type=py | head -20

echo -e "\n=== Verifying what happens when importing a deprecated utility outside of tests ==="
echo "The deprecation warning is only added to an internal set when imported."
echo "It is only logged when flush() is called, which happens during test execution."
echo "This means standalone imports of deprecated utilities produce no user-visible warning."

Repository: avocado-framework/avocado

Length of output: 728

Critical issue: Deprecation warnings are not shown for direct imports—only during test execution.

The log_deprecation.warning() call at module import only adds the utility name to an internal set and does not emit any user-visible warning. Warnings are deferred and only logged when log_deprecation.flush() is called, which currently happens only once in the codebase during test execution in avocado/plugins/runners/avocado_instrumented.py.

This means users who import deprecated utilities directly (not as part of a test) receive no warning whatsoever, defeating the purpose of deprecation notices. The implementation requires:

  1. Immediate warning on import (either via logging.warning() or Python's warnings module)
  2. Ensure the warning is always emitted, not deferred until test execution
  3. Add tests that verify deprecation warnings are visible to users
  4. The migration guidance (AAutils reference) is correct but unreachable for non-test usage
🤖 Prompt for AI Agents 
In @avocado/utils/gdb.py around lines 899-902, The current call to
log_deprecation.warning("gdb") in avocado/utils/gdb.py only records the
deprecation internally and defers emission until log_deprecation.flush() is
called elsewhere, so direct imports never show a warning; change this to
immediately emit a user-visible deprecation (e.g., call warnings.warn(...,
DeprecationWarning) or logging.warning(...) with a clear message and include the
AAutils migration guidance), and keep or update log_deprecation.warning("gdb")
if you still want the centralized tracking but ensure you also call
log_deprecation.flush() or directly emit the warning at import time so it’s not
deferred; then add unit tests that import avocado.utils.gdb directly and assert
that a DeprecationWarning or the logging output is produced when imported.

6 changes: 6 additions & 0 deletions avocado/utils/process.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1459,3 +1459,9 @@ def get_command_output_matching(command, pattern):
['file1.txt', 'file2.txt']
"""
return [line for line in run(command).stdout_text.splitlines() if pattern in line]


# pylint: disable=wrong-import-position
from avocado.utils.deprecation import log_deprecation

log_deprecation.warning("process")
Comment on lines +1464 to +1467
Copy link

@gemini-code-assist gemini-code-assist bot Dec 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Using a custom log_deprecation object with a bottom-of-file import for deprecation warnings is a possible pattern, but it deviates from standard Python practices. The built-in warnings module is the idiomatic way to handle deprecations.

Using warnings.warn() would:

  • Adhere to PEP 8 by allowing the import to be at the top of the file.
  • Provide users with standard mechanisms to filter or handle these warnings (e.g., via warnings.simplefilter or the -W command-line option).
  • Avoid the need for a custom implementation and a flush() call.

Consider replacing this with a standard DeprecationWarning at the top of the module. For example:

# at the top of avocado/utils/process.py
import warnings

warnings.warn(
    "The 'process' utility is deprecated. It has been moved to the AAutils "
    "project and will be removed after the next LTS release. For more "
    "information, please see: https://github.com/avocado-framework/aautils",
    DeprecationWarning,
    stacklevel=2
)

If the custom log_deprecation is required for project-specific logging aggregation, please disregard this suggestion.

References
  1. PEP 8 recommends that imports should be at the top of the file. The current implementation places the import at the end of the file, which is a deviation from this standard. (link)

6 changes: 6 additions & 0 deletions avocado/utils/script.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -199,3 +199,9 @@ def make_temp_script(name, content, prefix="avocado_script", mode=DEFAULT_MODE):
scpt = TemporaryScript(name, content, prefix=prefix, mode=mode)
scpt.save()
return scpt.path


# pylint: disable=wrong-import-position
from avocado.utils.deprecation import log_deprecation

log_deprecation.warning("script")
Comment on lines +204 to +207
Copy link

@gemini-code-assist gemini-code-assist bot Dec 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Using a custom log_deprecation object with a bottom-of-file import for deprecation warnings is a possible pattern, but it deviates from standard Python practices. The built-in warnings module is the idiomatic way to handle deprecations.

Using warnings.warn() would:

  • Adhere to PEP 8 by allowing the import to be at the top of the file.
  • Provide users with standard mechanisms to filter or handle these warnings (e.g., via warnings.simplefilter or the -W command-line option).
  • Avoid the need for a custom implementation and a flush() call.

Consider replacing this with a standard DeprecationWarning at the top of the module. For example:

# at the top of avocado/utils/script.py
import warnings

warnings.warn(
    "The 'script' utility is deprecated. It has been moved to the AAutils "
    "project and will be removed after the next LTS release. For more "
    "information, please see: https://github.com/avocado-framework/aautils",
    DeprecationWarning,
    stacklevel=2
)

If the custom log_deprecation is required for project-specific logging aggregation, please disregard this suggestion.

References
  1. PEP 8 recommends that imports should be at the top of the file. The current implementation places the import at the end of the file, which is a deviation from this standard. (link)

6 changes: 6 additions & 0 deletions avocado/utils/wait.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -102,3 +102,9 @@ def wait_for(func, timeout, first=0.0, step=1.0, text=None, args=None, kwargs=No
time.sleep(step)

return None


# pylint: disable=wrong-import-position
from avocado.utils.deprecation import log_deprecation

log_deprecation.warning("wait")
Comment on lines +107 to +110
Copy link

@gemini-code-assist gemini-code-assist bot Dec 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Using a custom log_deprecation object with a bottom-of-file import for deprecation warnings is a possible pattern, but it deviates from standard Python practices. The built-in warnings module is the idiomatic way to handle deprecations.

Using warnings.warn() would:

  • Adhere to PEP 8 by allowing the import to be at the top of the file.
  • Provide users with standard mechanisms to filter or handle these warnings (e.g., via warnings.simplefilter or the -W command-line option).
  • Avoid the need for a custom implementation and a flush() call.

Consider replacing this with a standard DeprecationWarning at the top of the module. For example:

# at the top of avocado/utils/wait.py
import warnings

warnings.warn(
    "The 'wait' utility is deprecated. It has been moved to the AAutils "
    "project and will be removed after the next LTS release. For more "
    "information, please see: https://github.com/avocado-framework/aautils",
    DeprecationWarning,
    stacklevel=2
)

If the custom log_deprecation is required for project-specific logging aggregation, please disregard this suggestion.

References
  1. PEP 8 recommends that imports should be at the top of the file. The current implementation places the import at the end of the file, which is a deviation from this standard. (link)

Loading