Inconsistent case sensitivity (streamlit run, st.switch_page, and the file name)

[MathCatsAnd]

Checklist

• I have searched the existing issues for similar issues.
• I added a very descriptive title to this issue.
• I have provided sufficient information below to help reproduce this issue.

Summary

When using st.switch_page to go to your app's homepage on a Mac, the function is case sensitive to how the app was initialized with streamlit run and not with the actual file name.

Reproducible Code Example

#App.py

import streamlit as st

if st. button("a"):
    st.switch_page("pages/a.py")

#pages/a.py
import streamlit as st

if st.button("app"):
    st.switch_page("app.py")

if st.button("App"):
    st.switch_page("App.py")

Steps To Reproduce

On a Mac (I used Chrome, but the Mac is the important part.)

1. streamlit run App.py
2. Clicking the first button (app) on pages/a.py results in an error (can't find page).
3. Clicking the second button (App) works as expected.

On the other hand

1. streamilt run app.py (The app still runs)
2. Clicking the first button (app.py) works
3. Clicking the second button (App) results in an error.

When I do the same on a Windows computer, there's no problem either way. It's case insensitive.

Expected Behavior

I don't know if I'd expect a Mac to throw an error on streamlit run if the case doesn't match, but I definitely think st.switch_page (if it's going to be case sensitive) should match the case of the actual file.

Current Behavior

StreamlitAPIException: Could not find page: App.py. Must be the file path relative to the main script, from the directory: Sandbox. Only the main app file and files in the pages/ directory are supported.

Is this a regression?

• Yes, this used to work in a previous version.

Debug info

• Streamlit version:
• Python version:
• Operating System:
• Browser:

Additional Information

No response

[github-actions]

If this issue affects you, please react with a 👍 (thumbs up emoji) to the initial post.

Your feedback helps us prioritize which bugs to investigate and address first.

[Asaurus1]

@MathCatsAnd are you working on this or do you want me to take a stab at it? I can at least cover Linux and Windows (don't have a Mac to test on). I think the behavior on Linux might actually be a third option: it is more restrictive than Windows or Mac since you cannot start the app unless the file name case matches exactly, so you don't get into a situation where you have an indeterminate starting state.

Testing on Ubuntu on streamlit 1.34.0:

1. streamlit run app.py fails
2. "App.py" button works
3. "app.py" button fails

[sfc-gh-dmatthews]

I've got my hands full on documentation, so the devs will need to comment on how they want to prioritize and approach this. (And yes, Linux should be tested, too. I just had a Mac laptop and Windows laptop on my desk, so I started there to get the report in.) 😁

[kajarenc]

Thank you @MathCatsAnd for reporting this!
Definitely agree that this is an issue

@snehankekre IMHO this could fit well in Coherence and Completeness track, and also rhymes a little with pathlib.Path support for file paths project too. I mark this as P3 for now, but leave the last word to you on the matter of priority, so please feel free to change to another priority

[Asaurus1]

@kajarenc dug into this a little more. Unfortunately I'm not even sure that pathlib.Path is necessary a fix-all solution here. until about Python 3.12, pathlib.Path has a fixed preference for POSIX-like systems (it treats them as case sensitive) even though OSX file-systems are typically case-insensitive like on Windows (although that can be modified by the user).

Python 3.12 seems to do better by using a system call to os.fspath to "normalize" a path, which allows the user's filesystem to determine whether two paths are equal.

If we're willing to accept that, however, then

# execution_control.py
matched_pages = [p for p in all_app_pages if Path(p["script_path"]) == Path(requested_page)]

would do the trick for this particular bug. Or, one could store the Path objects themselves in source_util.get_pages.

[Asaurus1]

@sfc-gh-jcarroll I imagine the st.nagivation changes might screw around with the existing script_path code a bunch, so to avoid conflicts with that I think it would at least make sense to wait to fix this until after that API is settled down.

[sfc-gh-jcarroll]

defer to @kmcgrady but yeah that may make sense - this will be a good one to fix though! Thx for flagging Debbie, Alex and Karen!