From: Edward Cree <ecree.xilinx@gmail.com>
To: "Michalik, Michal" <michal.michalik@intel.com>,
Jakub Kicinski <kuba@kernel.org>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"pabeni@redhat.com" <pabeni@redhat.com>,
"edumazet@google.com" <edumazet@google.com>,
"Kubalewski, Arkadiusz" <arkadiusz.kubalewski@intel.com>
Subject: Re: [PATCH net] tools: ynl: add the Python requirements.txt file
Date: Mon, 20 Mar 2023 22:16:09 +0000 [thread overview]
Message-ID: <560bd227-e0a9-5c01-29d8-1b71dc42f155@gmail.com> (raw)
In-Reply-To: <BN6PR11MB41772BEF5321C0ECEE4B0A2BE3809@BN6PR11MB4177.namprd11.prod.outlook.com>
On 20/03/2023 19:03, Michalik, Michal wrote:
> From: Jakub Kicinski <kuba@kernel.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
next prev parent reply other threads:[~2023-03-20 22:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-14 16:07 [PATCH net] tools: ynl: add the Python requirements.txt file Michal Michalik
2023-03-16 4:40 ` Jakub Kicinski
2023-03-20 19:03 ` Michalik, Michal
2023-03-20 22:16 ` Edward Cree [this message]
2023-03-21 12:34 ` Michalik, Michal
2023-03-21 17:52 ` Jakub Kicinski
2023-03-21 18:52 ` Edward Cree
2023-03-23 10:33 ` Michalik, Michal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=560bd227-e0a9-5c01-29d8-1b71dc42f155@gmail.com \
--to=ecree.xilinx@gmail.com \
--cc=arkadiusz.kubalewski@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=michal.michalik@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).