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: <560bd227-e0a9-5c01-29d8-1b71dc42f155@gmail.com>
Date:   Mon, 20 Mar 2023 22:16:09 +0000
From:   Edward Cree <ecree.xilinx@...il.com>
To:     "Michalik, Michal" <michal.michalik@...el.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/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.

> 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].)

-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