get_data returning None on valid file path

[AYUSHJAIN951]

Describe the bug
Test.get_data() returning None on valid file path, as it calls filename

avocado/avocado/core/test.py

Line 433 in fd1d54b

possibly_compiled = inspect.getfile(self.__class__)

In the start of test, its called to fetch class module path, which occurs to be not absolute path, and which incurs issues when changing directories in test

This issue occurs upto python3.9 version, 3.10 onwards it works fine
But still on latest RHEL 3.9 is the default version, so should be fixed to provide absolute path of class module

Steps to reproduce

1. Start a test using [test](https://github.com/avocado-framework/avocado/blob/master/avocado/core/test.py)
2. check for logs: find Test metadata: in that filename parameter

python3.9.21
test.py
 
python3.10
/home/avocado-misc-tests/io/disk/test.py
 
python3.11
/home/avocado-misc-tests/io/disk/test.py

Here this filename is fetched using
inspect.getfile(self.__class__) -> which calls sys.modules.get(object.__module__)

Issue is occuring from here
sys.modules.get(object.__module__) this is returning localpath upto python3.9

python3.9.21
test.py
<module 'test' from 'test.py'>
 
python3.10
/home/avocado-misc-tests/io/disk/test.py
<module 'test' from '/home/avocado-misc-tests/io/disk/test.py'>
 
python3.11
/home/avocado-misc-tests/io/disk/test.py
<module 'test' from '/home/avocado-misc-tests/io/disk/test.py'>

Expected behavior
We expect absolute path for filename here

Current behavior
Local Path is returned in current state

System information (please complete the following information):

• OS:
  NAME="Red Hat Enterprise Linux"
  VERSION="9.5 (Plow)"
  ID="rhel"
  ID_LIKE="fedora"
  VERSION_ID="9.5"
  PLATFORM_ID="platform:el9"
  PRETTY_NAME="Red Hat Enterprise Linux 9.5 (Plow)"

• Avocado version: Avocado 109.0

• Avocado installation method: github

$ python3.9 --version
Python 3.9.21

$ python3.9 -m pip --version
pip 21.3.1 from /usr/lib/python3.9/site-packages/pip (python 3.9)

$ python3.11 --version
Python 3.11.9

$ python3.11 -m pip --version
pip 22.3.1 from /usr/lib/python3.11/site-packages/pip (python 3.11)

[AYUSHJAIN951]

@narasimhan-v FYI

[PraveenPenguin]

we had a patch posted at #5930, which is just trying to populate the full path in any case but @clebergnu has other views to handle in use case

[Naresh-ibm]

we had a patch posted at #5930, which is just trying to populate the full path in any case but @clebergnu has other views to handle in use case

Thanks for pointing this up. It helps.
I think we can close this issue too.

[AYUSHJAIN951]

Thank you @PraveenPenguin for pointing to that.
I see your and @clebergnu @richtja views on this
I see it in a little bit different way, i might be wrong so need all of yours views on this

This @filename its a integral part in Core API of avocado and is used to fetch file -> path
On different versions of python3 its returning either relative path or absolute path, which is a issue and needs to be addressed by making it either one of those.

python3.9.21
test.py
 
python3.10
/home/avocado-misc-tests/io/disk/test.py
 
python3.11
/home/avocado-misc-tests/io/disk/test.py

I think it should provide only absolute path on all versions of python3,
which can be achieved by using inspect.getabsfile() from cpython lib/inspect.py
https://github.com/python/cpython/blob/b8b4b713c5f8ec0958c7ef8d29d6711889bc94ab/Lib/inspect.py#L838

diff --git a/avocado/core/test.py b/avocado/core/test.py
index fedac7d7..03279872 100644
--- a/avocado/core/test.py
+++ b/avocado/core/test.py
@@ -430,7 +430,7 @@ class Test(unittest.TestCase, TestData):
         Returns the name of the file (path) that holds the current test
         """
         try:
-            possibly_compiled = inspect.getfile(self.__class__)
+            possibly_compiled = inspect.getabsfile(self.__class__)
             if possibly_compiled.endswith(".pyc") or possibly_compiled.endswith(".pyo"):
                 source = possibly_compiled[:-1]

[richtja]

Hi @AYUSHJAIN951, thanks for the report. We will probably need to add some new test to catch such issue in the future.

[richtja]

@AYUSHJAIN951 I just noticed that you have already a fixing commit in your fork. Can I assign fixing this to you? Your help would be really appreciated.

[AYUSHJAIN951]

@richtja sure you can assign it to me, I am testing it on my local currently will open PR shortly