-
-
Notifications
You must be signed in to change notification settings - Fork 7
[DO NOT MERGE] Modify tutorial to reflect isolated development mode. #44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
| [helloworld] Activating dev environment... | ||
| ... | ||
| Creating virtual environment (dev.cp313-win32_amd64)... done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this actually what the environment would be called? The other platforms say cpython rather than cp, and the wheel tag is win_amd64 rather than win32.
Likewise for the other examples in the tutorial.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. The naming is derived from the binary wheel extension on the platform. If you've got a 64-bit Intel build of Python, this is what the platform-identifying part of the binary wheel looks like. You can confirm this with binary wheels (e.g., the -cp313-cp313-win_arm64.whl wheel for Pillow contains PIL/_imaging.cp313-win_arm64.pyd.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually the naming is derived from importlib.machinery.EXTENSION_SUFFIXES[0], which isn't the same as the wheel tag in general. Based on my tests, for some reason they're not consistent about cpython vs cp. So the examples are all correct, except that it should be win_amd64, not win32_amd64.
|
Also, there are some spelling errors in the RTD build. |
🤦 Clearly I forgot to run lint before pushing. I've applied your suggestions manually (GitHub GUI was having issues with some of them because they were on "deleted lines"?), and corrected those spelling issues. |
NOTE: This should not be merged until Briefcase 0.4 is released.
beeware/briefcase#2593 modified how
briefcase devinteracts with requirements. This means some very slightly different output on first run ofbriefcase dev, and a change to tutorial 7 - users can'tpip install faker; they have to add it torequiresand runbriefcase dev -r. This content mostly existed already, as it was needed forbriefcase update -r; but now need that explanation sooner.beeware/briefcase#2592 also provides a better experience for missing system dependencies on Linux, which we can signpost at the appropriate points.
This updates the tutorial to reflect these changes.
PR Checklist: