On 6/22/20 6:42 AM, Adrian Turjak wrote:
Thomas, I think that's something that downstream maintainers will eventually need to seriously consider and figure out, because any modern front end service these days will end up being built with npm pieces, and various js libraries.
That's not like if we don't want to do it, it's just that it's kind of very hard considering the amount of work that it implies. So what would be your suggestion to fix the problem exactly?
The mindset of excluding or avoiding npm dependencies will cripple any attempt at any serious javascript development, and given the modern web is all JS interfaces, that doesn't particularly bode well for OpenStack from a visual interface perspective if the mindset is very anti-js. :(
Nobody is anti-js here. I'd love Horizon to become more dynamic. Sure, using NPM bindly and fetching any random dependency is fun, and comfortable for developers. But that's probably the only advantage. The issue is npm fetching an incredible number of dependencies which makes it super hard to package applications right way. To give you an example, I've heard that the number of node dependencies in Gitlab approaches the thousand (maybe 900+ ?). Each and every dependency has to be packaged individually, checked by the package maintainer, and peer reviewed by the Debian FTP team. If you have a solution to fix that hard problem, please shoot, and everyone in Debian (and other downstream distro) will be happy. In the mean time, packaging something that more or less matches "curl | sudo bash" (because that's more or less what "npm install" is...) is a no-go, and will be refused by absolutely everyone in Debian and other distros. The alternative solution would be: - get Horizon completely removed from downstream distributions. - push Horizon to non-free, or package it only in non-official repositories, including a "bundle" of all javascripts. FYI, there's also a long thread about packaging Kubernetes in Debian, and the problem is looking the same: there's about 150 Go libraries to package to reach the result. And there's problems with versions in Debian sometimes not matching the one of upstream. Again, the Debian community is open to suggestions to fix this, but so far, nobody was able to provide one that is satisfying. My own opinion on this, is that the Javascript "ecosystem" is completely broken, and another approach should be considered than the one of blindly fetching dependencies. The current npm way doesn't feel safe at all for something to put in production, as it could be the source of security problems. How, for example, does one ensures that none of the dependency contains malicious code that is gathering browsing information? How do you ensure there's no privacy breach? How do you know none of the upstream libraries are malicious? In Python, at least, there's a central repository, with administrator (trying to?) keeping things safe, and the chain of dependency isn't THAT insane. Cheers, Thomas Goirand (zigo)