Relative Paths To Compose File Fail in 1.3.0

[LArkema]

Describe the bug
Starting in podman-compose 1.3.0, compose files fail to open when provided as a relative path.

To Reproduce
Steps to reproduce the behavior:

1. what is the content of the current working directory:

- project/
   - docker-compose.yaml

2. what is the sequence of commands you typed

[user]# pwd
/home/user
[user]# podman-compose -f project/docker-compose.yml build

Expected behavior
The build process begins following the instructions in the compose file

Actual behavior
A FileNotFoundError is returned

[user]# podman-compose -f project/docker-compose.yml build
Traceback (most recent call last):
  File "/usr/local/bin/podman-compose", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/usr/local/lib/python3.11/site-packages/podman_compose.py", line 3711, in main
    asyncio.run(async_main())
  File "/usr/lib64/python3.11/asyncio/runners.py", line 190, in run
    return runner.run(main)
           ^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/asyncio/base_events.py", line 654, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/podman_compose.py", line 3707, in async_main
    await podman_compose.run()
  File "/usr/local/lib/python3.11/site-packages/podman_compose.py", line 1859, in run
    self._parse_compose_file()
  File "/usr/local/lib/python3.11/site-packages/podman_compose.py", line 1954, in _parse_compose_file
    with open(filename, "r", encoding="utf-8") as f:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: 'project/docker-compose.yml'

However, both local directory references ( podman-compose -f docker-compose.yml build executed from /home/user/project/ ) and absolute paths ( podman-compose -f /home/user/project/docker-compose.yml build executed from anywhere) work and read the compose file.

Output

# podman-compose version
podman-compose version 1.3.0
podman version 4.9.4-rhel

Environment:

• OS: Linux
• podman version: 4.9.4-rhel
• podman compose version: 9cbc4c1

Additional context

Add any other context about the problem here.

[lschmelzeisen]

Also running into this.

Seems to be the same issue as #1059?

[cfunkhouser]

Fundamentally, this bug is caused by the os.chdir(dirname), here:

podman-compose/podman_compose.py

Lines 1928 to 1929 in 51d180d

	# TODO: remove next line
	os.chdir(dirname)

To illustrate, consider the strace output of an invocation like podman-compose -f ./go/project/test.compose.yml up -d. You can see here the program searching for .env files in _parse_compose_file just before the failure, which is clearly caused by the chdir("/code/go/project") before reading the relative (to the previous CWD) file.

...
newfstatat(AT_FDCWD, "./go/project/test.compose.yml", {st_mode=S_IFREG|0644, st_size=384, ...}, 0) = 0
getcwd("/code", 1024)                   = 6
newfstatat(AT_FDCWD, "/code/go", {st_mode=S_IFDIR|0755, st_size=288, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(AT_FDCWD, "/code/go/project", {st_mode=S_IFDIR|0755, st_size=960, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(AT_FDCWD, "/code", {st_mode=S_IFDIR|0755, st_size=704, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(AT_FDCWD, "/code/go", {st_mode=S_IFDIR|0755, st_size=288, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(AT_FDCWD, "/code/go/project", {st_mode=S_IFDIR|0755, st_size=960, ...}, AT_SYMLINK_NOFOLLOW) = 0
newfstatat(AT_FDCWD, "/code/go/project/.env", 0xfffffefa8688, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/code/go/project/.env", 0xfffffefa8688, 0) = -1 ENOENT (No such file or directory)
getcwd("/code", 1024)                   = 6
newfstatat(AT_FDCWD, "/code/.env", 0xfffffefa8688, AT_SYMLINK_NOFOLLOW) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/code/.env", 0xfffffefa8688, 0) = -1 ENOENT (No such file or directory)
chdir("/code/go/project")               = 0
openat(AT_FDCWD, "./go/project/test.compose.yml", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

However, this bug was surfaced by the removal of the line normalizing compose files to absolute paths in #993. Before this line was removed, the absolute file paths would still work fine after the chdir.

The real fix is probably to remove that chdir call entirely, unless someone knows why that's there. That seems a little too obvious for no one to have tried, so alternatively, a fix for this might be to put back the files = list(map(os.path.realpath, files)) removed in #993 (and replace the vague TODO: remove next line with an actual description of why that line is there).

Is there anyone with more historical knowledge of the project that can weigh in on which is preferred? Perhaps @p12tic, who authored the change making files relative again?

[cfunkhouser]

This was fixed by #1124 for my use cases (but please, would love some more signal).

What would it take to get a bugfix release including #1124?