Unclarity in Single-sourcing version option 1

[soxofaan]

packaging.python.org/source/guides/single-sourcing-package-version.rst

Lines 8 to 11 in 526ee6d

	There are many techniques to maintain a single source of truth for the version
	number of your project:
	#. Read the file in :file:`setup.py` and get the version. Example (from `pip setup.py

states:

Read the file in ...

but it's not clear which file (there is no preceding discussion about a file).
The meaning can be somewhat guessed from the code snippet below it, but that limits the interpretation to package/__init__.py, while it could be applied to other options too (e.g. package/version.py)

[bhrutledge]

I think this whole document could/should be updated to favor methods that don't rely on setup.py, since the current recommendation to use setup.cfg. I also note that this is specific to setuptools, and there are now many other build backends, some of which probably have their own method of handling this.

I'm tempted to re-purpose this issue as "Update single-sourcing package version recommendations", and probably close #616 as a duplicate. Off the top of my head, I might list the options as:

• importlib.metadata (currently 5)
• Version-updating tools (currently 2)
• version = attr: package.__version__ (currently note in 1)
• setuptools_scm (currently 7)
• Methods from other build backends (flit, poetry, pdm, etc.)

I wonder if @jaraco and/or @henryiii have thoughts.

[pradyunsg]

My 2 cents: Let's start simple, and fix the sentence ambiguity first. We shouldn't need to block minor sentence structure improvements on doing a major updates of various pages. :)

[ChrisBarker-NOAA]

Here's a PR for more updates:

#1273

[ncoghlan]

Resolved in #1612