Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1214813 > unrolled thread

Bug#1083100: please bundle the more modern React UI

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1083100: please bundle the more modern React UI Antoine Beaupre <anarcat@debian.org> - 2024-10-01 18:00 +0200
    Bug#1083100: please bundle the more modern React UI Antoine Beaupré <anarcat@debian.org> - 2024-10-03 23:30 +0200
    Bug#1083100: please bundle the more modern React UI Antoine Beaupré <anarcat@debian.org> - 2024-10-04 00:30 +0200
    Bug#1083100: help needed on the Prometheus front Antoine Beaupré <anarcat@debian.org> - 2024-10-07 18:30 +0200
      Bug#1083100: help needed on the Prometheus front weepingclown <weepingclown@disroot.org> - 2024-10-07 19:00 +0200
      Bug#1083100: help needed on the Prometheus front Jérémy Lal <kapouer@melix.org> - 2024-10-07 19:10 +0200
        Bug#1083100: help needed on the Prometheus front Antoine Beaupré <anarcat@debian.org> - 2024-10-07 19:30 +0200
          Bug#1083100: help needed on the Prometheus front Jérémy Lal <kapouer@melix.org> - 2024-10-07 20:20 +0200

#1214813 — Bug#1083100: please bundle the more modern React UI

Package: prometheus
Severity: wishlist

Hi!

After reading through #1053243, I realized that Alertmanager is not
the only Prom thing that has a "modern" UI buried out of the Debian
package, but that Prometheus itself has a "React" UI available.

And now, checking on the unstable package, I see that the "classic" UI
has actually been completely removed from upstream. So far we're
bundling the classic UI in the package, but that's deemed to be
removed in the future.

Let's not do the alertmanager thing here, and somehow figure out how
to package this properly. I understand it's a gooey Javascript thing,
but we *do* have a bunch of Javascript things in Debian, and I think
it's a solveable problem. At least it doesn't look like it has Elm
compiler stuff?

According to:

https://github.com/prometheus/prometheus/tree/main/web/ui#pre-requisite

We need npm >= v7 (already in bookworm, even!) and nodejs >= 20 (in
trixie). I'm not *super* familiar with the javascript packaging, but
it *looks* like the package.json file is not completely hopeless:

https://github.com/prometheus/prometheus/blob/main/web/ui/package.json

... but of course, it hides the uglier part of it where you have react
and friends:

https://github.com/prometheus/prometheus/blob/main/web/ui/mantine-ui/package.json

... but we *do* have react and friends and debian now! So I think it
might be worth tackling that one and looking at what, exactly, we're
missing from Debian that we could add to make this work and keep
having a working web UI in Prometheus for the forseeable future.

Thanks!

-- System Information:
Debian Release: 12.7
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (1, 'experimental'), (1, 'unstable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.10.6+bpo-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages prometheus depends on:
ii  adduser                                  3.134
ii  fonts-glyphicons-halflings               1.009~3.4.1+dfsg-3
ii  init-system-helpers                      1.65.2
ii  libc6                                    2.36-9+deb12u8
ii  libjs-bootstrap4                         4.6.1+dfsg1-4
pn  libjs-eonasdan-bootstrap-datetimepicker  <none>
ii  libjs-jquery                             3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-hotkeys                     0~20130707+git2d51e3a9+dfsg-2.1
pn  libjs-moment                             <none>
pn  libjs-moment-timezone                    <none>
pn  libjs-mustache                           <none>
ii  libjs-popper.js                          1.16.1+ds-6
pn  libjs-rickshaw                           <none>

Versions of packages prometheus recommends:
pn  prometheus-node-exporter  <none>

prometheus suggests no packages.

[toc] | [next] | [standalone]

#1215064

On 2024-10-03 22:59:42, Daniel Swarbrick wrote:
> I think you know as well as I do that the likelihood of this being 
> feasible is pretty remote.

I know, but i think it's worth, if not trying, at least keeping track of
how and why it's not possible. :)

> The fact that sufficient versions of npm, nodejs and React are already
> available in Debian does not help much if the web app uses a ton of
> bleeding edge modules which are not even on anybody's radar to package
> for Debian. Combine that with the fact that the Prometheus web UI is
> getting yet another major overhaul for v3.0.0.  It seems to be a
> fast-moving target.

Yeah, I'm kind of hoping they stop doing that already with the v3. But i
will note that people *are* trying to keep up with a lot of modules like
this for other projects, and I think it's actually possible to give it a
try already.

I would also argue *for* vendoring the stuff that's not practical to
package. We have a few special precedents in Debian for important
packages that have bent the rules a little bit to ship vendored copies
of source code (firefox and kubernetes, for example), and I think we
could get away with shipping a couple javascript libraries like this.

> The classic web UI was actually removed upstream in v2.34.0, and I have 
> forward-ported / reinstated the necessary Go code to keep supporting it. 
> This is a dead end however, since Prometheus has newer functionality 
> like exemplars and native (sparse) histograms, which are not supported 
> by the legacy web UI. I would prefer to see the Debian package finally 
> drop the classic UI also, since the Debian package is starting to 
> resemble more of a /fork/ of Prometheus.

Yep, this is mainly why I've opened that issue, actually.

> You may have noticed that I recently added an install-ui.sh helper 
> script to the prometheus package, to fetch the React web UI tarball from 
> upstream, similar to the script that is bundled with 
> prometheus-alertmanager. So you /can/ use the React web UI now, if you want.

Yes, I've seen that! I have even tried it out, but it didn't work out so
well for me, something which could perhaps be filed as a separate bug.

> If you're willing to pitch in and help package the React UI, by all 
> means, please do.

I will be honest and admit this is a request more than an offer, but
I *might* get time to deal with this in the coming *year* (aka "2025",
definitely not until January), so I wanted to see if there was at least
*some* openness in dealing with it.

Also, we're not alone with this: there's a bunch of people working on
JavaScript stuff in Debian, and we could get some help there.

So the question is: do we, as a golang team (and you, as an uploader for
this package), want to do this? Or do we want to fundamentally object to
even trying to fix this issue?

Because this is essentially why i filed this issue: I don't expect
anyone to just drop everything and do this. I want to see if people are
okay with us trying to do this.

Thanks for considering my request, in any case! :)

A.

[toc] | [prev] | [next] | [standalone]

#1215070

On 2024-10-04 00:14:50, Daniel Swarbrick wrote:
> On 03.10.24 23:21, Antoine Beaupré wrote:

[...]

>> I would also argue *for* vendoring the stuff that's not practical to
>> package. We have a few special precedents in Debian for important
>> packages that have bent the rules a little bit to ship vendored copies
>> of source code (firefox and kubernetes, for example), and I think we
>> could get away with shipping a couple javascript libraries like this.
>
> If the Prometheus package gets a pass in that respect, it would surely 
> make things a lot simpler, as we could stop de-blobbing the embedded 
> assets, and basically not have to give any thought whatsoever to 
> building the UI from scratch. I'm not sure how likely this is though.

I'm actually wondering if we could build two different binary packages:
one stripped down, without the react core (which would be useful
anyways!) and one with the blobs, that could perhaps be shipped in
contrib...

[...]

> It definitely looks better than it did a couple of years ago when I 
> looked into this,

yes! i looked too, and this is also why i felt confident filing this bug
:)

> but there are still a fair number of "[???]" 
> occurrences, where I was not able to find any packages that resemble 
> what is being referred to.

Yep, those are the sticky bits. :)

-- 
Only in the darkness can you see the stars.
                        - Martin Luther King, Jr.

[toc] | [prev] | [next] | [standalone]

#1215620 — Bug#1083100: help needed on the Prometheus front

Hi!

I'm part of the golang team (in CC) which is responsible for packaging
the Prometheus package, a golang-based monitoring system. Recently,
upstream switched from a "classic" HTML-based interface to a rather
more... complicated JavaScript frontend built with React.

We've looked at packaging this in Debian (#1083100, also in CC), and
quickly got worried about the number of dependencies we'd need to
package.

Do you have advice on how to move forward on this?

I was wondering if there's some magic command we can run to actually get
a more solid view on the tasks needed? Like a command that would parse
the package.json and report which packages are missing from Debian,
which have WNPP bugs, etc...

How involved is it to package React stuff?

How maintainable is it in the long run in Debian?

Thanks for any advice!

a.

-- 
The odds are greatly against you being immensely smarter than everyone
else in the field. If your analysis says your terminal velocity is
twice the speed of light, you may have invented warp drive, but the
chances are a lot better that you've screwed up.
                        - Akin's Laws of Spacecraft Design

[toc] | [prev] | [next] | [standalone]

#1215625 — Bug#1083100: help needed on the Prometheus front

[Multipart message — attachments visible in raw view] — view raw

Hi,

There is npm2deb. Running `npm2deb depends -b -r <pkg name in npm dot js>` can give you an idea about the dependency tree (the commands might be a bit different, it's been a while since I last dealt with it). Although I have to warn you that it is...... *very slow*.

Best,
Ananthu

On 7 October 2024 4:21:55 pm UTC, "Antoine Beaupré" <anarcat@debian.org> wrote:
>Hi!
>
>I'm part of the golang team (in CC) which is responsible for packaging
>the Prometheus package, a golang-based monitoring system. Recently,
>upstream switched from a "classic" HTML-based interface to a rather
>more... complicated JavaScript frontend built with React.
>
>We've looked at packaging this in Debian (#1083100, also in CC), and
>quickly got worried about the number of dependencies we'd need to
>package.
>
>Do you have advice on how to move forward on this?
>
>I was wondering if there's some magic command we can run to actually get
>a more solid view on the tasks needed? Like a command that would parse
>the package.json and report which packages are missing from Debian,
>which have WNPP bugs, etc...
>
>How involved is it to package React stuff?
>
>How maintainable is it in the long run in Debian?
>
>Thanks for any advice!
>
>a.
>
>-- 
>The odds are greatly against you being immensely smarter than everyone
>else in the field. If your analysis says your terminal velocity is
>twice the speed of light, you may have invented warp drive, but the
>chances are a lot better that you've screwed up.
>                        - Akin's Laws of Spacecraft Design
>

[toc] | [prev] | [next] | [standalone]

#1215627 — Bug#1083100: help needed on the Prometheus front

[Multipart message — attachments visible in raw view] — view raw

Le lun. 7 oct. 2024 à 18:27, Antoine Beaupré <anarcat@debian.org> a écrit :

> Hi!
>
> I'm part of the golang team (in CC) which is responsible for packaging
> the Prometheus package, a golang-based monitoring system. Recently,
> upstream switched from a "classic" HTML-based interface to a rather
> more... complicated JavaScript frontend built with React.
>
> We've looked at packaging this in Debian (#1083100, also in CC), and
> quickly got worried about the number of dependencies we'd need to
> package.
>
> Do you have advice on how to move forward on this?
>
> I was wondering if there's some magic command we can run to actually get
> a more solid view on the tasks needed? Like a command that would parse
> the package.json and report which packages are missing from Debian,
> which have WNPP bugs, etc...
>
> How involved is it to package React stuff?
>
> How maintainable is it in the long run in Debian?
>
> Thanks for any advice!
>
> a.
>

Can you give the link to the upstream package.json file that pulls the
dependencies, thanks.

[toc] | [prev] | [next] | [standalone]

#1215629 — Bug#1083100: help needed on the Prometheus front

On 2024-10-07 18:58:38, Jérémy Lal wrote:
> Le lun. 7 oct. 2024 à 18:27, Antoine Beaupré <anarcat@debian.org> a écrit :
>
>> Hi!
>>
>> I'm part of the golang team (in CC) which is responsible for packaging
>> the Prometheus package, a golang-based monitoring system. Recently,
>> upstream switched from a "classic" HTML-based interface to a rather
>> more... complicated JavaScript frontend built with React.
>>
>> We've looked at packaging this in Debian (#1083100, also in CC), and
>> quickly got worried about the number of dependencies we'd need to
>> package.
>>
>> Do you have advice on how to move forward on this?
>>
>> I was wondering if there's some magic command we can run to actually get
>> a more solid view on the tasks needed? Like a command that would parse
>> the package.json and report which packages are missing from Debian,
>> which have WNPP bugs, etc...
>>
>> How involved is it to package React stuff?
>>
>> How maintainable is it in the long run in Debian?
>>
>> Thanks for any advice!
>
> Can you give the link to the upstream package.json file that pulls the
> dependencies, thanks.

Of course! I believe it is:

https://github.com/prometheus/prometheus/blob/main/web/ui/mantine-ui/package.json

... which is called from:

https://github.com/prometheus/prometheus/blob/main/web/ui/package.json

i *think* the "react-app/" directory is the older implementation, which
can be disregarded.

Thanks!

-- 
La seule excuse de Dieu, c'est qu'il n'existe pas.
                        - Stendhal

[toc] | [prev] | [next] | [standalone]

#1215633 — Bug#1083100: help needed on the Prometheus front

[Multipart message — attachments visible in raw view] — view raw

Le lun. 7 oct. 2024 à 19:18, Antoine Beaupré <anarcat@debian.org> a écrit :

> On 2024-10-07 18:58:38, Jérémy Lal wrote:
> > Le lun. 7 oct. 2024 à 18:27, Antoine Beaupré <anarcat@debian.org> a
> écrit :
> >
> >> Hi!
> >>
> >> I'm part of the golang team (in CC) which is responsible for packaging
> >> the Prometheus package, a golang-based monitoring system. Recently,
> >> upstream switched from a "classic" HTML-based interface to a rather
> >> more... complicated JavaScript frontend built with React.
> >>
> >> We've looked at packaging this in Debian (#1083100, also in CC), and
> >> quickly got worried about the number of dependencies we'd need to
> >> package.
> >>
> >> Do you have advice on how to move forward on this?
> >>
> >> I was wondering if there's some magic command we can run to actually get
> >> a more solid view on the tasks needed? Like a command that would parse
> >> the package.json and report which packages are missing from Debian,
> >> which have WNPP bugs, etc...
> >>
> >> How involved is it to package React stuff?
> >>
> >> How maintainable is it in the long run in Debian?
> >>
> >> Thanks for any advice!
> >
> > Can you give the link to the upstream package.json file that pulls the
> > dependencies, thanks.
>
> Of course! I believe it is:
>
>
> https://github.com/prometheus/prometheus/blob/main/web/ui/mantine-ui/package.json
>
> ... which is called from:
>
> https://github.com/prometheus/prometheus/blob/main/web/ui/package.json
>
> i *think* the "react-app/" directory is the older implementation, which
> can be disregarded.
>

Thanks,

I think the proper method will be to mut-bundle as much, and as cleanly, as
possible,
with most packages not re-exported to /usr/share/nodejs, because it is just
asking for trouble.

There are tools to help in that task, like pkgjs-tools' add-node-component.
It requires some skills. I can help, but I don't have time to do it
entirely.
It's going to be difficult to get this into trixie, unless someone works
really hard on it right now.

--
We won't have a theory of everything without a theory of consciousness
  - David J. Chalmers

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web