[horizon] patternfly?

Thomas Goirand zigo at debian.org
Tue Jun 23 23:19:04 UTC 2020

On 6/23/20 9:48 PM, Tristan Cacqueray wrote:
> NPM can nest dependencies within a dependency when there are
> unsolvable conflicts, resulting in many node_modules directories.
> There are options to force a flat install, without nested node_modules,
> but you may get incompatible versions resulting in a broken build.
> Well I've tried that without success to package the >1600 nodejs
> dependencies required by grafana-5.2.3 .

1600 !!! Impressive.

>> 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.
> Could XStatic somehow works for typescript (Angular) or JSX (React) ?
> If I understand correctly, those frameworks require a toolchain to
> transpile the code to JS.

Well, if I'm not mistaking, the package node-typescript has been in
Debian since at least Stretch, so I don't think that's a problem (and
there's also a bunch of JSX packages in Buster).

> Otherwise it seems like the packaging concern you are raising may
> be too much of an issue as such frameworks are quite an important
> requirements for many modern JS applications.

The issue I'm raising isn't forbidding NPM and modern JS. The issue is
making sure it stays reasonable and manageable. What you described for
Grafana for example, doesn't feel like a reasonable approach to me.

> Considering how entangled the JS requirements are, is it really worth
> it to bother with individual packages compared to a bundle produced from
> a lock file where a bot like dependabot can propose updates when a
> dependency has an known issue?

What you're describing is what prevents things like Gitlab to get into
Debian, for example. What I've raised as an issue isn't just my own
opinion, but strong rules we have in Debian: no JS bundle made with "npm
install" will make it into the Debian repositories, everything *MUST* be
packaged separately. Even if I agree to the rule, I am not the person
who wrote it or enforce it.

> Another solution would be to avoid JS entirely and to use a safer language
> like Elm or PureScript which seems to have a saner approach to
> dependencies, but that is not an option for existing JS code base :-)

None of which are in Debian for the moment. Running this:
npm install -g purescript

failed for me in Buster. Oh, but that's more than 2 weeks old, so it
must be already obsolete ... :) Let's throw away that VM before it
explodes on me. :P


Thomas Goirand (zigo)

More information about the openstack-discuss mailing list