Re: Status and future of npm and go support

Stefan Herbrechtsmeier

Am 18.01.2022 um 15:37 schrieb Bruce Ashfield:
On Tue, Jan 18, 2022 at 9:27 AM Stefan Herbrechtsmeier
<stefan.herbrechtsmeier-oss@...> wrote:

Am 18.01.2022 um 15:10 schrieb Bruce Ashfield:
On Tue, Jan 18, 2022 at 9:04 AM Richard Purdie
<richard.purdie@...> wrote:

On Tue, 2022-01-18 at 15:00 +0100, Stefan Herbrechtsmeier wrote:
Am 18.01.2022 um 14:40 schrieb Richard Purdie:
On Tue, 2022-01-18 at 14:00 +0100, Stefan Herbrechtsmeier wrote:
In summary we use a language specific lock file based approach which
support offline build, license checks and CVE scans and leaves the
dependency management and fixing outside of OE to limit the recipe count
and required resources.
I think so. It isn't the perfect solution but it is what will likely be the most

Should this be unified between Node.js / npm, Go, Rust / Cargo and
Python / Pipfile?
I don't think it makes sense to dictate that and make a hard rule. Where there
are many dependencies and we can't easily control the dependency mechanism in
the language, yes. Not everything has as granular dependencies as npm though.
But do we have a consensus that we prefer existing lock files and a
specific fetcher instead of a multi line SRC_URI generated by recipetool?
I think either can be acceptable, it really depends on the situation.
For go, I've been working on a generated SRC_URI (via a .inc file) for
the source dependencies (but the low level tool to do that is outside
of recipetool, as it is something simple and I don't want it bound into
a larger tool's workflow).

If someone did figure it out within recipetool, I'd happily throw out my
more focused effort (since it isn't done yet, and I'm not sure how
long it will take to complete).
Do you extract the licenses from dependencies and populate the license
It's done at the source level, just the same way that we've been manually
checking vendor/ subdirectories up until now (except better, since we can
scan and checksum more easily). And that is done when generating the
SRC_URI. Again, I'm only talking about go here, since that is where I spend
most of my time in meta-virt. So this may be completely wrong for other
languages or use cases I haven't run into.
Is it possible to see the code?

Do you prefer to populate the SRC_URI or would a direct use of the lock
file inside a fetcher okay for you?
I use the SRC_URI, since I also use the fetcher prefix/subdir to position the
clones where they will be picked up for the build, and that means the
dependencies are very visible and part of a normal recipe hash/sstate/etc,
But if similar functionality was possible via a language specific lock file,
I wouldn't object.
Both solutions have advantages. The SRC_URI approach is known to OE developers but the manifest and lock file is supported by the language tools. I'm really unsure which way to go.

Join { to automatically receive all group messages.