Anyone has a mac machine and can help me debug this? Not sure why the tests get stuck...

Anyone has a mac machine and can help me debug this? Not sure why the tests get stuck...

I have a Mac, but haven't tried setting up RustPython on it yet...will try that

edit: @palaviv I got it set up relatively quickly (compared to the first time I tried), what do you need to test?

@jamestwebber reverting this commit would result error 03cc8ee

@jamestwebber reverting this commit would result error 03cc8ee

Well this probably isn't helpful but the test passed for me. I'm on this branch but commented out that line.

However, the other tests aren't passing (failed to import selenium), so maybe my setup is not correct.

I tested a bit and it seems generatedd relative path actually has problem even out of python.

• mkdir /var/folders/yf/dvzgtwmx7bsfgfc2d6mcldvh0000gn/T/tmpgsukx1jw success
• mkdir ../../../../var/folders/yf/dvzgtwmx7bsfgfc2d6mcldvh0000gn/T/tmpgsukx1jw fails

when the upper directory T exists and the same.

I ran the test with this command:
cargo run --release Lib/test/test_py_compile.py -k test_relative_path

When running same test on CPython, the mkdir directory is something like tmpmpse8rrx instead of long ../ chain. So I suspect os.path.relpath is somehow different from CPython.

Because this PR is not about os.path, I suggest to create a new issue for relpath and mark the test as expectedFailure for macOS

@youknowone the test start hanging when I marked the test as skip. How can a test that does not run be a problem?

I am sorry to be late. I checked out and run this PR, but didn't find any hanging point in local machine.

probably this is not hanging but just hit the timeout

By fixing #2007, I now believe the CI problem here also will be fixed by rebasing it over #2010. Would you try rebase it?

By fixing #2007, I now believe the CI problem here also will be fixed by rebasing it over #2010. Would you try rebase it?

Thanks. I will try that.