[docs] Documentation consistency fixes across doc/ folder

doc/dev/engineering_assumptions.md

@@ -6,7 +6,7 @@
 [bdist_wheel]
 universal=1
 ```
-2. If a package does _not_ have `universal` set, then the default build will produce a wheel for `py3`. This is due to the fact that wheels are currently generated by a CI step running `Python 3.6`.
+2. If a package does _not_ have `universal` set, then the default build will produce a wheel for `py3`. This is due to the fact that wheels are currently generated by a CI step running `Python 3.9`.
 
 ## Build
 

doc/dev/release.md

@@ -39,10 +39,10 @@ Validate artifacts prior to clicking `approve` on the release stage for the pack
 
 To build a package manually:
 ```
-python .\build_package.py azure-mgmt-myservice
+python -m build sdk/<service-dir>/azure-mgmt-myservice
 ```
 
-This will a sdist and a wheel file. This requires `wheel` package installed in your environment.
+This will produce a sdist and a wheel file. This requires the `build` package installed in your environment (`pip install build`).
 
 If you want to manually release on a regular basis, you should create a .pypirc:
 ```

doc/dev/static_type_checking.md

@@ -114,7 +114,8 @@ given the expressiveness of Python as a language. So, in practice, what should y
     - include the path to the `py.typed` in the
       MANIFEST.in ([example](https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/core/azure-core/MANIFEST.in)).
       This is important as it ensures the `py.typed` is included in both the sdist/bdist.
-    - set `include_package_data=True` and `package_data={"azure.core": ["py.typed"]}` in the setup.py.
+    - for packages using `pyproject.toml`, add `pytyped = ["py.typed"]` under the `[tool.setuptools.package-data]` section.
+      For packages still using `setup.py`, set `include_package_data=True` and `package_data={"azure.core": ["py.typed"]}` in the setup.py.
       Note that the key should be the namespace of where the `py.typed` file is found.
 
 2) Add type hints anywhere in the source code where unit tests are worth writing. Consider typing/mypy as "free" tests

doc/dev/tests.md

@@ -30,11 +30,11 @@ testing infrastructure, and demonstrates how to write and run tests for a servic
 
 ## Set up your development environment
 
-The Azure SDK Python team creates libraries that are compatible with Python 3.8 and up. We walk through setting up a
-Python virtual environment for Python 3.8, but having a virtual environment for each minor version can make it
+The Azure SDK Python team creates libraries that are compatible with Python 3.9 and up. We walk through setting up a
+Python virtual environment for Python 3.9, but having a virtual environment for each minor version can make it
 easier to debug PRs locally.
 
-- Python 3.8+: Use the [python website](https://www.python.org/downloads/) or the one-click experience from the Windows store ([3.8](https://www.microsoft.com/p/python-38/9mssztt1n39l), [3.9](https://www.microsoft.com/p/python-39/9p7qfqmjrfp7), [3.10](https://www.microsoft.com/p/python-310/9pjpw5ldxlz5), [3.11](https://apps.microsoft.com/detail/9nrwmjp3717k?hl=en-us&gl=US), [3.12](https://apps.microsoft.com/detail/9ncvdn91xzqp?hl=en-us&gl=US)) (Windows only).
+- Python 3.9+: Use the [python website](https://www.python.org/downloads/) or the one-click experience from the Windows store ([3.9](https://www.microsoft.com/p/python-39/9p7qfqmjrfp7), [3.10](https://www.microsoft.com/p/python-310/9pjpw5ldxlz5), [3.11](https://apps.microsoft.com/detail/9nrwmjp3717k?hl=en-us&gl=US), [3.12](https://apps.microsoft.com/detail/9ncvdn91xzqp?hl=en-us&gl=US), [3.13](https://apps.microsoft.com/detail/9ncvdn91xzqp)) (Windows only).
 
 
 ```cmd
@@ -57,8 +57,7 @@ In the root directory of our SDK, a number of mandatory files have been added. W
 
 - README.md. This is the description and guidance for customers or your SDK. Please see the guide on writing a README to make sure you have the complete [content requirements and formatting](https://review.learn.microsoft.com/help/platform/reference-document-sdk-client-libraries#readme).
 - CHANGELOG.md. This is where you will add the summary of changes for each new release. Please see [the guidance](https://azure.github.io/azure-sdk/policies_releases.html#changelog-guidance) for correct formatting.
-- setup.py. This is the 'installer' for your Python SDK. Please see [the guide on Python packaging][packaging] for details on customizing this for a specific package.
-- setup.cfg. This is an artifact used in building the Python package. Please see [the guide on Python packaging][packaging] for details.
+- pyproject.toml. This is the package metadata and build configuration for your Python SDK. Please see [the guide on Python packaging][packaging] for details on customizing this for a specific package.
 - MANIFEST.in. This is an artifact used in building the Python package. Please see [the guide on Python packaging][packaging] for details.
 - dev_requirements.txt. This is for developers, and lists the packages required for running the tests and samples. See the dependency installation section below.
 - sdk_packaging.toml. This configuration is used by the packaging pipeline and no further modifications should be required.

doc/eng_sys_checks.md

@@ -430,7 +430,7 @@ Workflow of this test is as follows when running regression for an SDK package.
 Steps to manually run regression test locally:
 
 1. Run below command from your git code repo to generate the wheel of package being developed. Currently we have restricted to have prebuilt wheel.
-`./scripts/devops_tasks/build_packages.py --service= <service-name> -d <out-folder>`
+`python -m build sdk/<service-name>/<package-name> --outdir <out-folder>`
 2. Run below command to start regression test locally
 `./scripts/devops_tasks/test_regression.py azure-* --service=<service-name> --whl-dir=<out-folder given above in step 2>`