jYdZddlmZddlZddlZddlmZmZmZddl m Z ddl m Z ddl mZdZd Zd ZddZddZefddZe\ZZgdZdS)u What version the code being imported actually is. ⛔ AN INSTALL RECORD IS NOT A DESCRIPTION OF THE CODE, AND FOR AN EDITABLE INSTALL IT STOPS BEING ONE THE MOMENT SOMEBODY PULLS. `importlib.metadata` answers about the DISTRIBUTION the installer put there. For a wheel that is the same artifact as the code, so the number is right and there is nothing truer to read. For `pip install -e` the metadata is written once and the code keeps moving, and nothing says the two have parted. Measured on the machine this is developed on, minutes after the checkout was brought to zero commits behind `origin/main`: the record said 0.16.2 while the tree said 0.22.1, six releases apart. Pulling does not touch the record, which is what makes this a defect in the code rather than a stale checkout. ⛔ AND THE NUMBER IS WHAT A MEASUREMENT NAMES. This package is the thing under test in every bench that drives a browser, so "measured against invisible-playwright X" is the sentence that carries the result. Read from the program, X was the moment somebody ran `pip install -e`, not the code being measured. A finding was about to be written with a version six releases wrong; it survived because its author had read the number off the TREE instead, which is luck rather than method. The rule those benches already carry - a red against an old dependency is not evidence about the product - keeps being broken because nothing answered "which version am I measuring?" truthfully. The version of the code is: - a normal install: the install record, because the metadata and the code came out of the same build; - an editable install: the version the SOURCE TREE declares, because that is the code that will run, plus a `+editable` local segment (PEP 440) so it can never be read as the published release of the same number. An editable tree can carry uncommitted work, so a bare `0.22.1` would invite a report against a release that does not contain the code being run. Which of the two an install is comes from what the installer WROTE, not from a guess about `__file__`: PEP 610 puts `direct_url.json` beside the metadata, carrying `dir_info.editable` and the source directory. A wheel install has no such file at all. The install record stays, under a name that cannot be mistaken for the version. `invisible_core` made this split first and names it the same way, deriving its own `__version__` from the seal it ships; it is not a shared implementation and must not become one by copying, because the core derives from an artifact it PACKAGES while this reads the tree an install points at. `aihawk` carries the same reading as this module for the same reason, so a correction here is worth looking at there. ) annotationsN) DistributionPackageNotFoundError distribution)Path)urlparse) url2pathnamezinvisible-playwrightz 0.0.0+unknownz +editabledistrreturn Path | Nonec|d}|sdS tj|}n#t$rYdSwxYwt |t sdS|dpidsdS|dpd}|dsdSttt|j S)zThe directory an EDITABLE install points at, or None for a normal one. Everything here is read from the record the installer wrote. The absence of `direct_url.json` is how a wheel install says it is one. zdirect_url.jsonNdir_infoeditableurlzfile:) read_textjsonloads ValueError isinstancedictget startswithrr rpath)r writtenrecordrs MC:\Projects\Muse2API\.venv\Lib\site-packages\invisible_playwright/_version.py source_treerCs nn.//G tG$$ tt fd # #t JJz " " (b - -j 9 9t **U   !rC >>' " "t  Xc]]/00 1 11s 0 >>treer str | Nonec tj|dz d}n#ttf$rYdSwxYw|dpid}t |tr|r|ndS)aThe version that source tree declares, or None when it does not say one. `pyproject.toml` is where the version lives and the metadata is a copy of it taken at build time, so this goes back to the source of the copy rather than adding a second source. A tree declaring `dynamic = ["version"]` says nothing readable without running its build backend, and answering None there falls back to the record, which is the same answer as before this module. zpyproject.tomlzutf-8)encodingNprojectversion)tomllibrrOSErrorrrrstr)rparseddeclareds r declared_byr*\s $ $ / / / A ACC Z tt 9%%+00;;H!(C00 GX G884Gs+.AAnamer'tuple[str, str]c t|}n#t$r tdfcYSwxYw|j}t |}|||fSt |}|||fS|t z|fS)a(the version of the CODE, the version in the install record). The two differ exactly when the install is editable and the tree has moved since it was installed, which on a machine where this is developed is most of the time. `name` is a parameter so the behaviour can be tested against a real editable install of a real distribution rather than against a double. r)rrUNKNOWNr$rr*EDITABLE)r+r rrr)s rversionsr0nsD!! {\F t  D |v~4  Hv~ h  &&s (() __version____install_record_version__r0rr* DISTRIBUTIONr/r.)r rr r )rrr r )r+r'r r,)__doc__ __future__rrr%importlib.metadatarrrpathlibr urllib.parserurllib.requestr r3r.r/rr*r0r1r2__all__rr=s..^#""""" OOOOOOOOOO!!!!!!''''''&   22222HHHH$&'''''4+3(**' ' P P Pr<