David Hotham

this is a variation on "recording `package.optional` in `poetry.lock` is a bad idea". https://github.com/python-poetry/poetry/issues/3188 is another example. in this case it is `get_extra_package_names()` that does not recognise that `importlib-metadata` is...

Pretty sure it isn't, maybe the luck of which `sphinx` happens to show up first during `get_extra_package_names()` is unstable

Apparently I knew about this at https://github.com/python-poetry/poetry/pull/6372#issue-1360542275

This is not a solved issue

could be worse: - failure to install on macos - looks like the problem is `cffi` - per https://github.com/python-cffi/cffi/issues/23 there is apparently a pre-release out - which does not do...

I might have mixed up poetry and poetry-core, `PYTHONWARNDEFAULTENCODING` is only turned on in poetry-core eg in the poetry-core pull request https://github.com/python-poetry/poetry-core/actions/runs/9750266660/job/26909309129?pr=742 > Run poetry run python -m pytest -p...

re-ran following the release of cffi 1.17.0, pretty much working now. Just one over-specified testcase that mysteriously is ever so slightly different on macos python 3.13.

or, maybe, make the tests run with a worker pool of size one so that they are not exposed to this sort of thing (I did take a brief look...

Plainly poetry is activating the environment. Perhaps you have code in your .bashrc or whatever that always puts pyenv at the front of the path. Whatever is happening is going...

the lockfile contains ```toml [[package]] name = "burr" version = "0.27.2" ... [package.dependencies] ... requests = {version = "*", optional = true, markers = "extra == \"tracking-server\""} ``` which has...