> On Jun 21, 2024, at 3:39 AM, Stuart Henderson <s...@spacehopper.org> wrote:
>
> On 2024/06/21 09:00, Laurent Cheylus wrote:
>> Hi Daniel,
>>
>> ----- Mail original -----
>>>> On Jun 19, 2024, at 9:35 AM, Laurent Cheylus <f...@free.fr> wrote:
>>>> a simple update for devel/flake8 to the latest version 7.1.0.
>>
>>> Thanks for the submission.
>>>
>>> Looks like pycodestyle has to be updated simultaneously.
>>
>> I have also an update for devel/py-codestyle to the latest version 2.12.0. I
>> will send it ASAP.
>>
>> But there is a problematic RDEP in devel/py-python-lsp-server 1.11.0 with
>> this update:
>> devel/py-codestyle${MODPY_FLAVOR}>=2.11.0,<2.12.0
>
> Check if it works anyway. Some of these deps are over-restrictive
> (in some cases they're only done so that "pip install" doesn't pull in a
> newer version of a dep, for example if that newer version doesn't
> support a Python version which some software wants to stay running on).
> Some build systems enforce these version number checks, some don't.
>
Unfortunately that doesn't work well in my experience.
Sometimes reverse deps ports enforce dependencies more strictly than our ports
infrastructure. So it makes doing future updates harder. And the same for
adding new ports which is common for the dev environments.
I’d rather stick to what upstream says they want. At least for the spyder and
Jupyter subset of our ports tree I’d prefer not to go that route.
For other parts of the python stack this could be ok if the dependency tree is
shallow and if someone checks carefully why the dependency change was made. And
that should be stated that it was checked. Although the code checkers do often
have real tight dependencies among themselves.
For python-lsp-server the next step might be to check if latest upstream git
has made an update and what was involved. I’m aware there is no newer release
of that port yet. But if they did a commit in git it could help give some clues
about whether the dependency is tight for a good reason or not.
