Add new package diagnostic/glances

[mebenn]

Glances is a monitoring tool like htop, but provides many more features. It has a rich selection of plugins to extend its functionality.

[mtelka]

I believe the build process will produce same results even with the above three lines removed. If so, then please remove them. If not, then please share the differences.

[mebenn]

I need either PYTHON_VERSIONS or PYTHON_VERSION, as I obtain this:
...>gmake env-prep
...
pkg install: No matching version of library/python/importlib-metadata-37 can be installed:
Reject: pkg://openindiana.org/library/python/[email protected]
...

[mtelka]

This is because you have library/python/importlib-metadata in PYTHON_REQUIRED_PACKAGES. I'm curious how it appeared there. It should list library/python/importlib_metadata instead. Is your system up-to-date?

[AndWac]

Please check the output of "pkg info userland-incorporation". The latest is FMRI: pkg://openindiana.org/consolidation/userland/[email protected]:20221021T131054Z from a few minutes ago. It shouldn't be much older.

[mebenn]

i had to update, am now at
FMRI: pkg://openindiana.org/consolidation/userland/[email protected]:20221021T131054Z
which is just a few hours old.
Now, gmake env-prep moans:
pkg list: no packages matching the following patterns are installed:
/library/python/importlib-metadata-37
Adding required packages to build environment...
This error is resolved by including:
PYTHON_VERSIONS= 3.9

[AndWac]

Regarding the remove of PYTHON_VERSIONS= 3.9: There is a subtle difference between what happens with or without this: If you don't have it, there will be builds in the build folder for every python version (3.7 and 3.9 at the moment).

[mtelka]

...> pkg list -a | grep importlib

@mebenn: Your output is strange for several reasons.

First, there is (openindiana.org) in the output so you very like have non-default/non-standard publisher setup (pkg publisher output would tell us more).

Second, it miss some lines. The expected output should be something like this:

# pkg list -a | grep importlib
library/python/importlib-metadata-27              1.5.2-2020.0.1.2           --o
library/python/importlib-metadata-35              1.5.2-2020.0.1.1           i--
library/python/importlib-metadata-37              1.5.2-2020.0.1.2           i-r
library/python/importlib-metadata-39              1.5.2-2020.0.1.2           i-r
library/python/importlib_metadata                 4.10.1-2022.0.0.0          i--
library/python/importlib_metadata-37              4.10.1-2022.0.0.0          i--
library/python/importlib_metadata-39              4.10.1-2022.0.0.0          i--
#

Third, even with your strange pkg list -a | grep importlib output I do not understand how you got library/python/importlib-metadata in PYTHON_REQUIRED_PACKAGES. Is your workspace up-to-date (git pull)?

[mtelka]

Regarding the remove of PYTHON_VERSIONS= 3.9: There is a subtle difference between what happens with or without this: If you don't have it, there will be builds in the build folder for every python version (3.7 and 3.9 at the moment).

This is valid point. Yes, you are right. But that should be the only difference (plus a bit longer build time). The resulting package should be the same. If we want to avoid that right now I believe the best way is to set PYTHON_VERSIONS = $(PYTHON_VERSION).

This is also reason why we need to order builds for various Python versions. I removed this ordering recently (mistakenly) so I'll return it back for now until some better solution is implemented.

[mtelka]

Yes, but we have again some failing packages due to these changes. Furthermore, I found another difference (new vs. old):

< set name=pkg.fmri value=pkg:/$(COMPONENT_FMRI)-$(PYV)@$(IPS_COMPONENT_VERSION),$(BUILD_VERSION)

set name=pkg.fmri value=pkg:/$(COMPONENT_FMRI)@$(IPS_COMPONENT_VERSION),$(BUILD_VERSION)

The automatic addition of $(PYV) to package fmri could be suppressed using GENERATE_EXTRA_CMD= in component's Makefile.

BTW, I plan to implement better (and simpler) support for python components that do not need to be build for multiple pythons (like this one, or ansible, etc), but first I'd like to complete fully automatic integration of versioned python components.

OTOH, if these components (glances, ansible, and so on) are built as versioned python packages, then they would be easier to integrate now. AFAIK, versioned python packages have only one con I'm aware about: there is set of packages, instead of single package, but the main package name will stay, so no big difference for end users.

[mebenn]

Here's my current env:
I'm up-to-date...
...> git log
`...
commit 774110f (upstream/oi/hipster)
Author: Marcel Telka [email protected]
Date: Fri Oct 21 06:47:57 2022 +0200

perl/B-COW: update to 0.007

...
`
i.e., my (rebase) commits are above the the commit today at 6:47, and commits below I've omitted. So update looks ok.

# pkg list -a | grep importlib library/python/importlib-metadata-27 1.5.2-2020.0.1.2 --o library/python/importlib-metadata-35 1.5.2-2020.0.1.1 i-- library/python/importlib-metadata-37 1.5.2-2020.0.1.2 i-r library/python/importlib-metadata-39 1.5.2-2020.0.1.2 i-r library/python/importlib_metadata 4.10.1-2022.0.0.0 i-- library/python/importlib_metadata-37 4.10.1-2022.0.0.0 i-- library/python/importlib_metadata-39 4.10.1-2022.0.0.0 i-- #...> uname -a
SunOS oi 5.11 illumos-ea524515bd i86pc i386 i86pc benn@oi:~/devl/oi/oi-userland/components$

I've also noticed a problem with glances-3.9 in the bin dir. I tried to resolve this by removing $(PYV) (in glances.p5m) from the fmri to obtain
set name=pkg.fmri value=pkg:/$(COMPONENT_FMRI)@....
and then coping /usr/bin/glances-3.9 to /usr/bin/glances in COMPONENT_POST_INSTALL_ACTIONS; but this is horrible.
So I still think that I require PYTHON_VERSION=3.9 to avoid different builds for different Python versions.
I'll have a look tomorrow and be on IRC if anyone happens to be about.
Cheers, thanks for the help

[mtelka]

I think you do not need the $(COMPONENT_SRC)/ part here.

[mtelka]

Where this file comes from? It lacks the copyright/license header.

[mebenn]

I don't know much about Mate. I copied /usr/share/applications/htop.desktop to glances.desktop and configured. Now the htop package self does not contain any htop.desktop, so I assume this was generated by Mate??
It would be even easier if I could generate a .desktop for glances.

[mtelka]

Then, maybe, it would be better to do not include this file? Since Glance seems to be a terminal utility we do not need desktop file for it, IMHO.

[AndWac]

BTW: This package is also a candidate as we don't want to have /usr/bin/glances-3.9

[mtelka]

Hmmmm. This seems to be a nice candidate for python-integrate-project integration. Did you try to integrate using $WS_TOOLS/python-integrate-project Glances? It might be a bit harder to create the first integration, but all future maintenance and upgrades would be far far easier.

[AndWac]

sample-manifest.p5m differs here: it contains usr/bin/glances-$(PYVER)

[mtelka]

To get usr/bin/glances in sample-manifest.p5m too you need to add COMPONENT_POST_INSTALL_ACTION= to Makefile after the common.mk include.

[AndWac]

@mebenn: Does glances work on your system?
I have tried it:
╰─➤ glances
Traceback (most recent call last):
File "/usr/bin/glances", line 33, in
sys.exit(load_entry_point('Glances==3.2.7', 'console_scripts', 'glances')())
File "/usr/bin/glances", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.9/importlib/metadata.py", line 86, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.9/importlib/init.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1030, in _gcd_import
File "", line 1007, in _find_and_load
File "", line 986, in _find_and_load_unlocked
File "", line 680, in _load_unlocked
File "", line 850, in exec_module
File "", line 228, in _call_with_frames_removed
File "/usr/lib/python3.9/vendor-packages/glances/init.py", line 35, in
from glances.compat import PY3
File "/usr/lib/python3.9/vendor-packages/glances/compat.py", line 39, in
from defusedxml.xmlrpc import monkey_patch
ModuleNotFoundError: No module named 'defusedxml'

It looks like there is a missing runtime dependency on defusedxml for which we need to have a package first.

[mtelka]

It looks like there is a missing runtime dependency on defusedxml for which we need to have a package first.

To create such package you could just run $WS_TOOLS/python-integrate-project defusedxml and if everything goes well (no ERROR or FATAL) just review the created changeset, push it, and create PR.

[mebenn]

@AndWac
Yes, the pkg install diagnostic/glances definitely worked, so why?
It got installed via pip (I originally installed glances a long time ago using pip, which must have installed defusedxml):

...> pip list | grep defusedxml
defusedxml 0.7.1

So it is indeed on my system. So I'll try python-integrate-project defusedxml tomorrow

[AndWac]

Is this still relevant? It looks like nobody cares anymore...

[mebenn]

@AndWac
Yes, would like to finish this, just didn't get any time; and I still care ever more so.