[UX] Explain that creating a Python package is useful even if you will never upload it to PyPI

[zackw]

The packaging tutorial should have an alternative intro that explains that creating a Python package gives you the ability to split up a program into multiple Python source files, and the ability to list your program’s dependencies so they can be automatically installed from PyPI (pip install -r requirements.txt, Hatch environments, etc.)

This is for people who are accustomed to writing self-contained single-file #! /usr/bin/python3 scripts that depend only on the standard library and perhaps also packages installed manually via the system package manager. It might need to be a whole new tutorial all by itself, and a new onboarding “funnel” from the top level of the website, because people with this reason to create a package probably don’t know that a package is what they need.

(Some of what’s already listed under “Why create a Python package” does touch on the above, but if you don’t already know that packages are relevant to your problem, you may not realize that that’s what it’s talking about.)

[willingc]

Next action: Pathway for going from a script to a package. Related to https://peps.python.org/pep-0723/

[lwasser]

wow @zackw another really good insightful issue!! thank you for all of the thought that you put into all of these issues. so i actually see two potential use cases here that are very much in scope for our tutorial work around code --> module or sharing code.

1. the case when a user has a single script that might need to be run - this might be a very specific workflow that is a single file and they might just want to share the file + dependencies. In that case the pep that supports //scripts would be very useful (and there is some talk around how this would be supported by conda - if we use hatch i believe it can be done (discussed in another issue but right now i forget which one).
2. The second usecase is for a scientists /person that has a much more complex code base that contains several files and perhaps modules that depend on each other etc. or perhaps a user that has a GIGANTIC script that would benefit greatly from being both reusable and organized in a more expressive, easier-to maintain way. That user also could create a "package" use the pyproject.toml file to declare and install dependencies + optional dependencies if that makes sense. And could share their code with themselves locally and with others via a github install.

Do those two use cases resonate @zackw ? i can actually see two distinct tutorials here that we could work on and flesh out that would likely help a lot of people.