Open Stack

On 6/23/20 2:53 AM, Jeremy Stanley wrote:
> I think it's perfectly valid to want software which is mature enough
> to have ABI versioning and generous compatibility ranges for its
> dependency chain, and which sticks to a minimal set off
> well-established requirements rather than just grabbing whatever's
> shiny and new.

If it was only just "whatever's shiny and new" this would only be half a
disaster. It's not. The current JS mentality is more among the line of:
"whatever random version, even an outdated one filled with security
holes, if I want to, because I'm a lazy programmer and I don't care
upgrading (what for?), that version works, so please get off my lawn,
you're annoying, I'm just pinning this version and that's it!"...

Unfortunately, the above behavior is widely accepted in the JS world
that each and every library should be carefully picked-up to avoid this
black hole trap.

Anyone dismissing how huge of a problem this is, isn't doing serious
programming, for serious production use. That person would just be doing
script kiddy work in the playground. Yes, it works, yes, it's shiny and
all. The upstream code may even be super nice, well written and all. But
it's *NOT* serious to put such JS bundling approach in production.

On 6/23/20 5:51 AM, Akihiro Motoki wrote:
> The point I would like to mention is why we need to avoid using the
> well-known dependency management systems in the JavaScript community
> from the beginning.

Hopefully, you understand the problem isn't specific to distributions,
but also to any sysadmin which is pushing such a library bundle online.

We need to avoid NPM because it's broken by design. Not really because
of NPM itself, but because of how it's used in the JS community:
clarelessly.

Every language has its own management system, each being worse than the
other. By far, I would consider NPM the most horrible one I even met.
The result is always that:
- NPM gets multiple versions of the same library (because that's how
things are expressed)
- NPM discards the older one randomly (because only one version can be
there), and...
- the result gets compress and bundled with a tool that isn't even safe,
into a single file (which is faster to load).

Yes, I do consider nodejs-uglify as something dangerous that one should
try to avoid: there's been proven security hole with it (please don't
trust my words, and do your own research on it, it's easy to find, a few
years ago someone even opened a thread in the
debian-devel at lists.debian.org list about it).

On 6/23/20 5:51 AM, Akihiro Motoki wrote:
> I think the problem is not which system(s) we use
> for dependency management. What we need is to define a proper
> versioning strategy in the project at some point of maturity of a
> software.

The dependency management tool you're going to use is going to have a
huge influence on how you manage the dependencies. With NPM, one clearly
decides the way of: "I don't care how or what, I just care about the
shiny page result".

> Back to packaging, I am also not sure whether the xstatic mechanism
> should continue.
> All updates in their upstreams need to be checked (manually now) and
> we usually tend to be behind it even if there is a security update.
> "Double packaging" is not efficient. Horizon upstream packages JS
> libraries into xstatic and distros packages it into their packages.

The effort using the XStatic thing was to be able to de-embed javascript
from the rest of Horizon. I wouldn't mind changing to another system,
but that system *MUST* provide the same enhancements we saw with XStatic:

1/ Enable de-embedding of JS libraries from Horizon (and plugins).
2/ Being easily fetched for testing in our (python based) gate.
3/ Artifacts can easily be replaced by the distro-specific version.

I currently don't see another way than XStatic. If you do, please share.
We've discussed multiple times that it is contributor time consuming,
we're all aware of it but found no other approach so far.

BTW, if you didn't notice, some of the de-embedding in plugins to
XStatic has been done by myself (in cloudkitty if IIRC?), and recently,
by Michal Arbet (who's co-maintaining OpenStack in Debian with me, and
who did 5 new XStatic for vitrage-dashboard). So if you feel packaging
new stuff is too much work, we can help: embed it first, and we'll do
the de-embedding work.

I'm also hereby volunteering if you need help with upgrading to the
latest version of the package (ie: I'll help with XStatic Python
packaging itself, not the code that's calling it...). Just ping me on
IRC whenever you need me for that.

Cheers,

Thomas Goirand (zigo)