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@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)