chore: update poetry.lock file for dependabot

[pqvr]

Description

Resolving the (closed) dependabot issues in one MR (which was done by regenerating the poetry.lock file from scratch:

• chore(deps-dev): bump h11 from 0.14.0 to 0.16.0 #222
• chore(deps-dev): bump tornado from 6.4.2 to 6.5.1 #223
• chore(deps-dev): bump setuptools from 78.1.0 to 78.1.1 #224

Please verify that you have completed the following steps

• I have self-reviewed my code.
• I have included test cases validating introduced feature/fix.
• I have updated documentation.

[mstechly]

I don't like the idea of adding h11 as an explicit dependency, since it's a transient dependency, we don't use it anywhere directly.
At least there should be a comment on why it's there.

[pqvr]

Yeah, that's true. The reason for adding it explicitly is because the version that we use 0.14.0 is less than the version for the fix proposed in #222 (0.16.0). I wanted to see if I could see where h11 might be coming from in the dependency tree and then update that meta-dependency. However, running:

$ poetry show h11 --tree                                                              

h11 0.16.0 A pure-Python, bring-your-own-I/O implementation of HTTP/1.1

doesn't give me the information about which dependency is bringing it in. Indeed, running the more verbose tree command:

$ poetry show --tree
black 24.10.0 The uncompromising code formatter.
├── click >=8.0.0
│   └── colorama * 
├── mypy-extensions >=0.4.3
├── packaging >=22.0
├── pathspec >=0.9.0
├── platformdirs >=2
├── tomli >=1.1.0
└── typing-extensions >=4.0.1
flake8 7.2.0 the modular source code checker: pep8 pyflakes and co
├── mccabe >=0.7.0,<0.8.0
├── pycodestyle >=2.13.0,<2.14.0
└── pyflakes >=3.3.0,<3.4.0
flake8-docstrings 1.7.0 Extension for flake8 which uses pydocstyle to check docstrings
├── flake8 >=3
│   ├── mccabe >=0.7.0,<0.8.0 
│   ├── pycodestyle >=2.13.0,<2.14.0 
│   └── pyflakes >=3.3.0,<3.4.0 
└── pydocstyle >=2.1
    └── snowballstemmer >=2.2.0 
h11 0.16.0 A pure-Python, bring-your-own-I/O implementation of HTTP/1.1
ipytree 0.2.2 A Tree Widget using jsTree
└── ipywidgets >=7.5.0,<9
    ├── comm >=0.1.3 
    │   └── traitlets >=4 
    ├── ipython >=6.1.0 
    │   ├── colorama * 
    │   ├── decorator * 
    │   ├── exceptiongroup * 
    │   ├── jedi >=0.16 
    │   │   └── parso >=0.8.4,<0.9.0 
    │   ├── matplotlib-inline * 
    │   │   └── traitlets * (circular dependency aborted here)
    │   ├── pexpect >4.3 
    │   │   └── ptyprocess >=0.5 
    │   ├── prompt-toolkit >=3.0.41,<3.1.0 
    │   │   └── wcwidth * 
    │   ├── pygments >=2.4.0 
    │   ├── stack-data * 
    │   │   ├── asttokens >=2.1.0 
    │   │   ├── executing >=1.2.0 
    │   │   └── pure-eval * 
    │   ├── traitlets >=5.13.0 (circular dependency aborted here)
    │   └── typing-extensions >=4.6 
    ├── jupyterlab-widgets >=3.0.12,<3.1.0 
    ├── traitlets >=4.3.1 (circular dependency aborted here)
    └── widgetsnbextension >=4.0.12,<4.1.0
....
(Rest of output from `-tree` command truncated)

IOW, it doesn't seem clear to me where precisely h11 is coming from. I can suggest two options:

1. Keep the h11 = "^0.16.0" dependency explicitly listed in the pyproject.toml file (although I also don't like transient dependencies, so maybe let's not opt for this one) and add a comment for descriptive purposes as to why this is listed, or
2. Remove the h11 dependency and be aware that chore(deps-dev): bump h11 from 0.14.0 to 0.16.0 #222 will still be flagged.

I think I would opt for Option 2, but I'm open to other options not listed here as well that might be better. Any thoughts, @mstechly ?

[mstechly]

I think the tree failed for you as you already had h11 specified in pyproject.toml.

When I ran it on a fresh repo I got:

├── jupyterlab >=4.3.6,<4.4
│   ├── async-lru >=1.0.0
│   │   └── typing-extensions >=4.0.0
│   ├── httpx >=0.25.0
│   │   ├── anyio *
│   │   │   ├── exceptiongroup >=1.0.2
│   │   │   ├── idna >=2.8
│   │   │   ├── sniffio >=1.1
│   │   │   └── typing-extensions >=4.5 (circular dependency aborted here)
│   │   ├── certifi *
│   │   ├── httpcore ==1.*
│   │   │   ├── certifi * (circular dependency aborted here)
│   │   │   └── h11 >=0.13,<0.15

So I went down that rabbithole and it looks like it's already fixed in httpcore (see this MR: encode/httpcore#1008), but it just has not been released yet.

So I would go with option 2, the problem will solve itself once they release it and we update poetry lock.

[pqvr]

Ah, good! Okay, Option 2 it is then: 08b0158