Open Stack

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)