netdev - RE: [PATCH net] tools: ynl: add the Python requirements.txt file

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BN6PR11MB41770D6527882D26403EF628E3819@BN6PR11MB4177.namprd11.prod.outlook.com>
Date:   Tue, 21 Mar 2023 12:34:50 +0000
From:   "Michalik, Michal" <michal.michalik@...el.com>
To:     Edward Cree <ecree.xilinx@...il.com>,
        Jakub Kicinski <kuba@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>
Subject: RE: [PATCH net] tools: ynl: add the Python requirements.txt file

On 20 March 2023 11:16 PM CET, Edward Cree wrote:
> 
> On 20/03/2023 19:03, Michalik, Michal wrote:
>> From: Jakub Kicinski <kuba@...nel.org> 
>>> Why the == signs? Do we care about the version of any of these?
>> 
>> I cannot (you probably also not) guarantee the consistency of the API of
>> particular libraries.
> 
> Assuming the libraries are following best practice for their version
>  numbering (e.g. semver), you should be able to use ~= ('compatible
>  version' [1]).
> For example, `jsonschema ~= 4.0` will allow any 4.x.y release, but
>  not 5.0.0 since that could have breaking API changes.
> I would recommend against pinning to a specific version of a
>  dependency; this is a development tree, not a deployment script.
>

This is actually a good idea. Let's wait for Jakub to confirm if he feels
the Python requirements file is a good idea in this case. If he confirms,
I would update the libraries according to your suggestion. Thanks.

>> No, you did not forget about anything (besides the PyYAML that you didn't
>> mention above). There is more than you expect because `PyYAML` and
>> `jsonschema` have their own dependencies.
> 
> Again I'd've thought it's better to let those packages declare their
>  own dependencies and rely on pip to recursively resolve and install
>  them.  Both on separation-of-concerns grounds and also in case a
>  newer version of a package changes its dependencies.
> (Probably in the past pinning all dependencies at the top level was
>  needed to work around pip's lack of conflict resolution, but this
>  was fixed in pip 20.3 [2].)

I agree with the comment that it is not a deployment script and that we
could leave only necessary packages and let pip do the rest of the job.
I will update if Jakub would decide he want to see the requirements here.

Thanks Edward for valuable input!

BR,
M^2

> 
> -ed
> 
> [1]: https://peps.python.org/pep-0440/#compatible-release
> [2]: https://pip.pypa.io/en/latest/user_guide/#changes-to-the-pip-dependency-resolver-in-20-3-2020