I'm already an expert on this topic, so I didn't expect to learn anything significant, and it's fine that I didn't (I did get to see a bit of the experience of using some tools that I haven't bothered with due to not needing their functionality for my own work).
I'm also not surprised that a video with this title is mostly a historical overview. That in itself seems to say something....
Some nitpicks:
* sdist stands for source distribution, not software distribution. This mistake is repeated many times throughout the video. Similarly, PyPI is officially supposed to be pronounced "pie pea eye", not "pie pie" (https://pypi.org/help/#pronunciation).
* At 6:35, there's a mention of the `dist-packages` directory used by the system installation of Python on Debian and downstream distros, which I thought was presented in a slightly confusing way. It should be noted that Pip won't install to there - it's for use with the system package manager.
* At 6:41, it was disappointing not to have any detail about how `sys.path` gets initialized. The video makes it sound as if the inclusion of `site-packages` were hard-coded, but actually there is quite a bit of flexibility here. For reference: https://docs.python.org/3/library/sys_path_init.html
* There were a couple of historical details that I couldn't directly confirm but which seem a bit suspect. For reference, Numpy has existed with that name since 2006 (and has its roots in older projects). I was unable to determine the release date for the first public release of Setuptools (this was apparently 0.3a1 (https://setuptools.pypa.io/en/latest/history.html), but no date is listed there, and PyPI only has releases back to 0.6. That release was in 2006, so the 2004 release date in the video is plausible, but I can't find independent confirmation. On the other hand, the repository history goes back all the way to 1998 (seemingly starting with just the distutils code, rather than some wrapper treating it as a dependency).
* At 27:09 it's claimed that you won't find musl wheels for major projects. That's questionable - for example, they're certainly offered for NumPy. The corresponding wheel tag has been standardized since 2021 (https://peps.python.org/pep-0656/).
* The overall description of pyproject.toml and setup.py seems a bit confused. Building with Setuptools doesn't require setup.py to be present if there's nothing for it to configure. But on the other hand, pyproject.toml doesn't obviate the need for setup.py if users will download an sdist and need to build non-Python code from it. pyproject.toml was not designed as either a Pipfile replacement nor a setup.py replacement - it specifies project metadata, with an emphasis on the information needed for building sdists and wheels. These issues are distributed throughout the second half of the video.
* flit isn't a Setuptools replacement either - by design, flit only handles pure Python projects, and aims for simplicity. Setuptools was once a complete development toolchain, according to an ancient understanding of what such a toolchain should include - but now it's only supposed to be used as a build backend. flit is still a complete project management tool - its build backend component is flit-core.
* At 38:44 it's said that "you always have Setuptools in a fresh virtualenv", but this is wrong. In 3.12, venv no longer includes it. (It also didn't include Pip in the initial implementation in 3.3, and from 3.4 onwards has supported optionally excluding Pip.) Nowadays Pip defaults to building wheels (whether it's trying to install an sdist, or explicitly via `pip wheel`) in an "isolated" environment, wherein it explicitly installs Setuptools if venv hasn't already provided it.
* The importance and danger of setup.py is both understated and overstated. On the one hand, as mentioned above, it's necessary for installing sdists that have to build non-Python code - that simply can't be configured through pyproject.toml. But on the other hand, setup.py can run even when just downloading an sdist using `pip download`. Because Pip insists on checking the metadata from what it just downloaded to make sure it matches the name and version you requested. (We're currently going through a slow and painful standardization process to allow Pip to trust that when PyPI is asked for foo 1.0.0 and gives back a file with a name that starts with foo-1.0.0, it actually represents foo 1.0.0. Seriously.) It should also be noted that running setup.py could become the bottleneck in solving dependencies, rather than network speed.
I'm also not surprised that a video with this title is mostly a historical overview. That in itself seems to say something....
Some nitpicks:
* sdist stands for source distribution, not software distribution. This mistake is repeated many times throughout the video. Similarly, PyPI is officially supposed to be pronounced "pie pea eye", not "pie pie" (https://pypi.org/help/#pronunciation).
* At 6:35, there's a mention of the `dist-packages` directory used by the system installation of Python on Debian and downstream distros, which I thought was presented in a slightly confusing way. It should be noted that Pip won't install to there - it's for use with the system package manager.
* At 6:41, it was disappointing not to have any detail about how `sys.path` gets initialized. The video makes it sound as if the inclusion of `site-packages` were hard-coded, but actually there is quite a bit of flexibility here. For reference: https://docs.python.org/3/library/sys_path_init.html
* There were a couple of historical details that I couldn't directly confirm but which seem a bit suspect. For reference, Numpy has existed with that name since 2006 (and has its roots in older projects). I was unable to determine the release date for the first public release of Setuptools (this was apparently 0.3a1 (https://setuptools.pypa.io/en/latest/history.html), but no date is listed there, and PyPI only has releases back to 0.6. That release was in 2006, so the 2004 release date in the video is plausible, but I can't find independent confirmation. On the other hand, the repository history goes back all the way to 1998 (seemingly starting with just the distutils code, rather than some wrapper treating it as a dependency).
* At 27:09 it's claimed that you won't find musl wheels for major projects. That's questionable - for example, they're certainly offered for NumPy. The corresponding wheel tag has been standardized since 2021 (https://peps.python.org/pep-0656/).
* The overall description of pyproject.toml and setup.py seems a bit confused. Building with Setuptools doesn't require setup.py to be present if there's nothing for it to configure. But on the other hand, pyproject.toml doesn't obviate the need for setup.py if users will download an sdist and need to build non-Python code from it. pyproject.toml was not designed as either a Pipfile replacement nor a setup.py replacement - it specifies project metadata, with an emphasis on the information needed for building sdists and wheels. These issues are distributed throughout the second half of the video.
* flit isn't a Setuptools replacement either - by design, flit only handles pure Python projects, and aims for simplicity. Setuptools was once a complete development toolchain, according to an ancient understanding of what such a toolchain should include - but now it's only supposed to be used as a build backend. flit is still a complete project management tool - its build backend component is flit-core.
* At 38:44 it's said that "you always have Setuptools in a fresh virtualenv", but this is wrong. In 3.12, venv no longer includes it. (It also didn't include Pip in the initial implementation in 3.3, and from 3.4 onwards has supported optionally excluding Pip.) Nowadays Pip defaults to building wheels (whether it's trying to install an sdist, or explicitly via `pip wheel`) in an "isolated" environment, wherein it explicitly installs Setuptools if venv hasn't already provided it.
* The importance and danger of setup.py is both understated and overstated. On the one hand, as mentioned above, it's necessary for installing sdists that have to build non-Python code - that simply can't be configured through pyproject.toml. But on the other hand, setup.py can run even when just downloading an sdist using `pip download`. Because Pip insists on checking the metadata from what it just downloaded to make sure it matches the name and version you requested. (We're currently going through a slow and painful standardization process to allow Pip to trust that when PyPI is asked for foo 1.0.0 and gives back a file with a name that starts with foo-1.0.0, it actually represents foo 1.0.0. Seriously.) It should also be noted that running setup.py could become the bottleneck in solving dependencies, rather than network speed.