beeware
Too Easy for Briefcase Apps to Clash with (semi-)Reserved Python Names
Describe the bug When a user creates a Briefcase app, the Formal Name is used as the internal name to reference and invoke the app. It includes the app's module name and entry point name among others. Therefore, unintuitive runtime errors can occur when this name collides with the standard library's module namespace or even its (pseudo-)entry points.
To Reproduce Some examples:
- a formal name of
socketwill immediately error since this is an existing module in the standard library that's imported early. - a formal name of
testmay run the CPython test suite (as in does with a packaged Flatpak). - a formal name of
mainincurs aRecursionErrorbecause default Briefcase entry point is also namedmain.
Expected behavior Briefcase should tell the user these names are not allowed or avoid name clashes altogether.
- Create a blocklist of names users should not use.
- This sets up a situation of whack-a-mole.
- Rework how internal naming works to make clashes less likely.
- I think the current naming is elegant and intuitive....so prepending
briefcase_(for instance) seems undesirable.
- I think the current naming is elegant and intuitive....so prepending
We already have a blocklist, populated with Python, Java, and Windows reserved words; this was introduced in #565 specifically as a response to #460 - the name "switch" is a reserved word in Java.
That list only uses language reserved words; extending it to include "names of modules in the Python standard library", plus some other key names of interest like "test" and "main" seems like a simple fix. It probably doesn't even need to be the full standard library - I'd be surprised if someone called their app wsgiref or this or distutils - but for the sake of completeness, I guess it couldn't hurt.
Yes, this will ultimately be whack-a-mole - but I think the moles will eventually become fairly endangered species as we add classes of names to this list :-)
I meant to add that I created this when I realized there wasn't a reliable list of semi-reserved names in Python. To that end, Python 3.10 introduced sys.stdlib_module_names...although, I found at least some debate about how this should be used/trusted. The isort team apparently created things like isort.stdlibs.py39 to determine what was part of the standard library in lieu of any support previously.
Another (bit half baked) idea I had was to preform a check to see if the user-provided name could be imported...the user could at least be warned about potentially creating a name clash then,
A bit aged but this is documenting in some depth how to find available modules.
At any rate....briefcase didn't create this problem....but it makes usability here a bit easier. I'll probably just implement an additional list of words to avoid for now.
