From: "Juraj Linkeš" <juraj.linkes@pantheon.tech>
To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
Cc: "thomas@monjalon.net" <thomas@monjalon.net>,
Wathsala Wathawana Vithanage <wathsala.vithanage@arm.com>,
"jspewock@iol.unh.edu" <jspewock@iol.unh.edu>,
"probb@iol.unh.edu" <probb@iol.unh.edu>,
"lijuan.tu@intel.com" <lijuan.tu@intel.com>,
"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>, nd <nd@arm.com>
Subject: Re: [PATCH v1 1/2] dts: fabric requirements
Date: Thu, 13 Apr 2023 09:49:47 +0200 [thread overview]
Message-ID: <CAOb5WZa2Vo2=U4hznAESJB3t1Wrg+Gx=vwcXZdrpN9Wy1PNj9Q@mail.gmail.com> (raw)
In-Reply-To: <CAOb5WZYKFjhmkqgG_L+-YR3LokAwLhDAdp98G-efvug24mCDdQ@mail.gmail.com>
On Thu, Apr 13, 2023 at 8:50 AM Juraj Linkeš <juraj.linkes@pantheon.tech> wrote:
>
> On Wed, Apr 12, 2023 at 5:38 PM Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Thomas Monjalon <thomas@monjalon.net>
> > > Sent: Wednesday, April 12, 2023 10:25 AM
> > > To: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > Cc: Wathsala Wathawana Vithanage <wathsala.vithanage@arm.com>;
> > > jspewock@iol.unh.edu; probb@iol.unh.edu; Honnappa Nagarahalli
> > > <Honnappa.Nagarahalli@arm.com>; lijuan.tu@intel.com;
> > > bruce.richardson@intel.com; dev@dpdk.org
> > > Subject: Re: [PATCH v1 1/2] dts: fabric requirements
> > >
> > > 12/04/2023 15:42, Juraj Linkeš:
> > > > On Tue, Apr 11, 2023 at 4:48 PM Thomas Monjalon <thomas@monjalon.net>
> > > wrote:
> > > > >
> > > > > 04/04/2023 13:51, Juraj Linkeš:
> > > > > > On Mon, Apr 3, 2023 at 5:18 PM Thomas Monjalon
> > > <thomas@monjalon.net> wrote:
> > > > > >
> > > > > > > 03/04/2023 16:56, Juraj Linkeš:
> > > > > > > > On Mon, Apr 3, 2023 at 2:33 PM Thomas Monjalon
> > > > > > > > <thomas@monjalon.net>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > 03/04/2023 13:46, Juraj Linkeš:
> > > > > > > > > > Replace pexpect with Fabric.
> > > > > > > > >
> > > > > > > > > You should squash these lines with the move to Fabric.
> > > > > > > > >
> > > > > > > > > > Signed-off-by: Juraj Linkeš <juraj.linkes@pantheon.tech>
> > > > > > > > > > ---
> > > > > > > > > > dts/poetry.lock | 553
> > > > > > > +++++++++++++++++++++++++++++++++++++++------
> > > > > > > > >
> > > > > > > > > Do we really need *all* these lines?
> > > > > > > > > I see a lot of lines about Windows and MacOSX which are not
> > > > > > > > > supported
> > > > > > > in
> > > > > > > > > DTS.
> > > > > > > > > It is so long that it looks impossible to review.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > This is a generated file and doesn't need to be reviewed.
> > > > > > >
> > > > > > > In general, I don't like storing generated files.
> > > > > > >
> > > > > >
> > > > > > Me neither, but this one is specifically designed to be stored in
> > > > > > a
> > > > > > repository:
> > > > > > https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock
> > > > > > -file-to-version-control
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > > I separated the
> > > > > > > > dependencies part so that the code part is easier to review.
> > > > > > > > If you
> > > > > > > want, I
> > > > > > > > can squash the two commits.
> > > > > > >
> > > > > > > What happens if we manually remove the useless lines?
> > > > > > >
> > > > > > >
> > > > > > The lock file is there so that everyone installs exactly the same
> > > > > > versions of dependencies. We can specify the versions of
> > > > > > dependencies in pyproject.toml, but we won't control the versions
> > > > > > of dependencies of dependencies this way. If we remove the changes
> > > > > > to the lock file, then we won't be storing tested versions,
> > > > > > everyone would be using slightly different versions and we may
> > > > > > potentially need to address versioning issues in the future - best to prevent
> > > that with a lock file.
> > > > >
> > > > > You didn't answer about removing the usuless lines, like unneeded Windows
> > > support.
> > > > >
> > > >
> > > > Do you mean the list of files from macos and windows? I tried removing
> > > > those from mypy and testing it and it looks like it didn't have an
> > > > impact, but I don't know the inner workings of poetry and the lock
> > > > file to test it properly (i.e. to rule out any breakages). What would
> > > > be the reason for removing those? Seems like it has more downsides (we
> > > > could potentially break something and it's extra work) than updsides
> > > > (as this is a generated file, I don't really see any).
> > >
> > > Yes this is what I mean.
> > > Any other opinion?
> > >
> > If it is a generated file, there might be an expectation from the tool that the file is not changed. It would be good to understand this.
> >
> > Since it is a generated file, should we generate this during DTS run time rather than storing a generated file?
> >
>
> The file is not used during runtime, but rather when installing
> dependencies. It's supposed to be generated by maintainers (once every
> time dependencies change or need updating) who verify the versions
> defined in the generated lockfile so that everyone then uses the same
> versions from that point on, preventing issues arising from different
> users using different versions of dependencies. So it's maintainers
> giving this file to other people.
>
> Juraj
I looked into this some more and I have some extra stuff to explain.
There's another patch that updates and cleans up the dependencies:
http://patches.dpdk.org/project/dpdk/patch/20230331091355.1224059-1-juraj.linkes@pantheon.tech/
To do this patch, I updated my Poetry version to 1.2.0 and apparently,
then changed the file lists of packages. Before, they had that in a
separate section and in Poetry 1.2.0 they separated it into packages.
This led to this patch having a lot of unrelated changes (in unrelated
dependencies) brought on by the Poetry upgrade. I'll submit an update
with just the pexpect/fabric switch and we can discuss the changes
brought by the Poetry update in the other patch.
prev parent reply other threads:[~2023-04-13 7:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-03 11:46 Juraj Linkeš
2023-04-03 11:46 ` [PATCH v1 2/2] dts: replace pexpect with fabric Juraj Linkeš
2023-04-24 13:35 ` [PATCH v2] " Juraj Linkeš
2023-04-28 19:03 ` Jeremy Spewock
2023-05-02 13:00 ` Juraj Linkeš
2023-05-03 17:54 ` Jeremy Spewock
2023-06-09 9:46 ` [PATCH v3] " Juraj Linkeš
2023-06-21 18:33 ` Jeremy Spewock
2023-07-05 19:59 ` Jeremy Spewock
2023-07-12 16:34 ` Thomas Monjalon
2023-07-09 1:45 ` Patrick Robb
2023-04-03 12:33 ` [PATCH v1 1/2] dts: fabric requirements Thomas Monjalon
2023-04-03 14:56 ` Juraj Linkeš
2023-04-03 15:17 ` Thomas Monjalon
2023-04-04 11:51 ` Juraj Linkeš
2023-04-11 14:48 ` Thomas Monjalon
2023-04-12 13:42 ` Juraj Linkeš
2023-04-12 15:24 ` Thomas Monjalon
2023-04-12 15:38 ` Honnappa Nagarahalli
2023-04-13 6:50 ` Juraj Linkeš
2023-04-13 7:49 ` Juraj Linkeš [this message]
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='CAOb5WZa2Vo2=U4hznAESJB3t1Wrg+Gx=vwcXZdrpN9Wy1PNj9Q@mail.gmail.com' \
--to=juraj.linkes@pantheon.tech \
--cc=Honnappa.Nagarahalli@arm.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=jspewock@iol.unh.edu \
--cc=lijuan.tu@intel.com \
--cc=nd@arm.com \
--cc=probb@iol.unh.edu \
--cc=thomas@monjalon.net \
--cc=wathsala.vithanage@arm.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).