On 2022-01-14 10:05, Stefan Herbrechtsmeier wrote:
Am 14.01.2022 um 15:15 schrieb Mark Asselstine via lists.openembedded.org:
On 2022-01-14 07:18, Alexander Kanavin wrote:
If we do seriously embark on making npm/go better, the first step
could be to make npm/go write out a reproducible manifest for the
licenses and sub-packages that can be verified against two recipe
checksums during fetch, and ensures no further network access is
necessary. That alone would make it a viable fetcher. Those manifests
could contain all needed information for further processing (e.g.
versions, and what depends on what etc.) And yes, it's a bundled
self-contained approach, but that matches how the rest of the world
is using npm.
I can't speak to npm but for go this was where I wanted to see things
go. Just as work was done to avoid unexpected downloads of Python eggs
I always felt the key to improving go integration was some for of
automated SRC_URI generation. Once this would be available it could be
leveraged for licensing and such.
Stefan, by the way the reason (a) is not possible is that multiple go
applications can use a shared 'library' but different versions (or
even different git commit ids).
Why is this simpler? The recipes need to list every information about
its dependencies. That means you repeat a lot of code and need to change
a lot of files if you update a single dependency.
We went through this with go recipes in meta-virt. It didn't work. You
end up producing a lot of Yocto Project specific files containing
information which is already available in other forms. Throw in the
multiple versions issue I described before and you get a mess. Large
reviews of content that maintainers will have to waste time to determine
what is needed to review and what can be ignored as it is just
transposed information... Again, the key is automation, that is what
makes things simpler.
The number of recipes and versions of recipes required to support go
applications quickly becomes difficult to manage.
How one big recipe instead of multi small recipes can solve this problem?
I am not pushing a big recipe. Keep the go recipes much as they are now,
but leverage the go tools to generate support artifacts.
MarkA
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1418):
https://lists.openembedded.org/g/openembedded-architecture/message/1418
Mute This Topic: https://lists.openembedded.org/mt/88417908/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
