One more thing that came to my mind is that the project is missing demo 
recipes/real life examples in core that actually would show that one can 
achieve reproducibility in the sense of the project's definition for 
both npm and go.
So far there is the fetcher code but real life users are living elsewhere.

So one could add consumers to core or push the code to where the "real 
action" is (meta-virt for instance comes to my mind)

On 25.12.21 21:43, Konrad Weihmann wrote:

What I so far don't really get is why increase in parsing time is such a 
big deal.
I admit when we're talking about npm it's some kind of a drastic 
increase in recipes one would have to maintain, just because some random 
project decides to use a trillion dependencies instead of writing two or 
three lines of code more.

Still I come to think this might be actually beneficial, as it shows how 
broken npm is from a distribution perspective - as it may be that some 
users actually start to access the situation when they are actually 
aware what monstrosity of a dep tree they are inheriting by just a 
single npm module.

So this is mind - and I don't want to sound radical - I would rather 
abandon npm and go support in core than to sacrifice closing the one 
main loophole in core that is preventing true accessibility at the moment.
Which is uncontrolled fetching outside of the fetching task, as this 
invalidates everything you will get in the end in terms of licensing, 
quality reports that haven't been done as part of the build and even CVE 
checking becomes pretty much worthless if one is allowed to inject 
random code on the fly into the build - and in the end everything that 
can't be assessed outside of the build is pretty much non-existing for 
most of the assessments I had to work with.

In the past I showed that npm and go can be made to work with these 
principles, even if they would introduce a different way of working and 
maybe the need for better tooling - *but* they can work with how oe-core 
works at the moment - to the expense of parsing time - and that's pretty 
much it from my point of view.

Still the gains outweigh it by far in my opinion, as it would make all 
of that accessible by common tooling already in place - including true 
reproducibility and builtin quality reports.

BTW I don't think rust and therefore cargo is heavily affected by it, as 
the cargo to bitbake scripting works kind in the way I would imagine for 
npm and go too - so far just npm and go are really really bad to handle 
in this case.

I'm happy to help on such scripting and tooling, but I don't see much 
worth in either accepting the fact that "modern languages" have to 
include some not validatable "magic" (which then would mean allowing 
uncontrolled network access) or working around the fact that a trillion 
dependencies is still a trillion dependencies no matter how you put it ( 
:) )

Regards
Konrad


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160008): https://lists.openembedded.org/g/openembedded-core/message/160008
Mute This Topic: https://lists.openembedded.org/mt/87909311/3647476
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [kweihmann@outlook.com]
-=-=-=-=-=-=-=-=-=-=-=-