[REGRESSION] 1.25.0 distributes "scripts" as a package

[KotlinIsland]

pypa/pip#1490 introduced an __init__.py into the scripts folder, this in turn made setuptools include it as a package to be installed.

👉 pip uninstall playwright      
Found existing installation: playwright 1.25.0
Uninstalling playwright-1.25.0:
  Would remove:
    c:\users\AMONGUS\...\lib\site-packages\playwright-1.25.0.dist-info\*
    c:\users\AMONGUS\...\lib\site-packages\playwright\*
    c:\users\AMONGUS\...\lib\site-packages\scripts\*
    c:\users\AMONGUS\...\scripts\playwright.exe
Proceed (Y/n)?

c:\users\AMONGUS\...\lib\site-packages\scripts\*?
This is highly sus and should be remediated immediately, maybe even yank the release, idk, up to you.

[rwoll]

Thanks for the report—and sorry for the inconvenience this has caused. We'll be looking into remediating this today.

[rwoll]

Distributing scripts as a package was not intended, and it will be fixed. It was introduced by #1490 to fix #1489.

Per #1489, there was unexplained breakage in the generation code. The "fix" was only intended to affect development, but due to an oversight, impacted the released package.

We'll be working to understand #1489 today, and take the appororiate resolution.

[rwoll]

@KotlinIsland / @DetachHead : Assuming #1505 passes, we'll be issuing a patch release (v1.25.1).

How'd we get here?

Without changing code, the Playwright Python builds started breaking overnight (relates #1489). Commits that had built clean one day, were not building clean the next. While we thought all deps were pinned (e.g. in local-requirements.txt) to ensure determinism and reproducability. It turns out they were not all pinned in the appropriate place (as evidenced by #1505 fixing the issue).

We mistakenly landed a workaround without fully understanding which part of the build was introduced the breakage, which in retrospect was a mistake. Sorry about that! We had diffed build logs from good and bad builds and determined the deps—at least those shown in the logs—were all identical versions, but turns out the issue ran deeper. We thought we were essentially implementing a workaround allowing us time to get to the bottom of the issue in the future, but overlooked the side effect of accidentally creating a new package.

Follow Up Actions

As a follow up, we will:

1. Publish v1.25.1
2. audit deps to determine which other build deps need to be pinned in pyproject.toml#build-system (e.g. like fix: pin setuptools in build-system #1505) [internal] ensure all build-system deps are pinned properly #1506
3. move to explicitly specifying include in setup.py to avoid accidentally creating new packages ([internal] move to inlcude, instead of exclude for setup.py #1504)
4. bisect setuptools versions to understand what change between 60.9.3 and 65.0.0 broke us; this will also allow us to upgrade setuptools in the future
5. and anything else the relates to the above

Thanks for your patience and understanding! Please let us know if you encounter any issues related to the above or have additional comments.

[rwoll]

1.25.1 has been released. I'll close this in favor of the individual follow up tickets linked above.

[KotlinIsland]

Awesome news on this @rwoll, glad to hear there was such a quick turnaround.

Are you going to yank 2.25.0? Maybe you should move to a modern dependency management and build system like Poetry.