I wrote a cron job!

[jonnin]

the stuff notepad++ has that I require used to be in visual studio. Its not a big set, but on top of standard bits (search/replace, line numbers, etc) I have to have rectangular text selection and repeat the keystrokes 'macros'. When visual studio took out macros, I stopped using its editor almost entirely.

[keskiverto]

TheIdeasMan wrote:

Ideally I would want it to be like this with dnf package manager, to install a reasonable starting point:

sudo dnf install neovim cpp cmake

That depends on distro. DNF repos are likely have "groups". One could see some with:

sudo dnf group list

and some more:

sudo dnf group list --hidden -v

On RHEL-like distro one of the groups is "Development Tools (development)"
and I could see info about it with one of:

sudo dnf group info -v "Development Tools"
sudo dnf group info -v development

Which gives me:

Group: Development Tools
 Group-Id: development
 Description: A basic development environment.
 Mandatory Packages:
   ...
 Default Packages:
   ...
 Optional Packages:
   ...

If I wanted (and did not have) those packages, then I could:

sudo dnf group install development

Alas, on el9 distro that has no neovim nor cpp, and cmake is optional.
It does have gcc, which pulls cpp as dependency and cmake could be included with:

sudo dnf install @development cmake

RHEL 9 does not have neovim, but third-party repo EPEL has it for RHEL 9.

sudo dnf install epel-release   # Defines EPEL on AlmaLinux and Rocky Linux
sudo dnf install @development cmake neovim

Another gotcha on el9 is that "system GCC" is (based on) version 11.5.
There is a way to get GCC 14:

sudo dnf install gcc-toolset-14 cmake neovim
scl enable gcc-toolset-14 bash

The latter command sets environment for bash instance to see the gcc 14 first.

That does not apply to all distros though.

[TheIdeasMan]

@keskiverto

Hi,

I see what you are saying about groups with dnf, and of course one should be to substitute their own package manager.

My hypothetical wish-list command is misleading, maybe it should have something like:

sudo dnf install @neovim -lsp cpp,cmake

Where: neovim is the group ; -lsp means Language Server Protocol; and the list following it are the actual lsp's. cmake lsp is there, so the editor can intelligently deal with cmake files.

There is a wikipedia page for LSP: basically it allows software to "understand" a language, and it is not limited to programming languages: it can do Domain Specific Languages too.

Some more detail about why I would like it to be easier, my understanding of it at least:

The prerequisites: A nerd font; the compilers, other obvious things

1. First we install neovim;
2. Then a neovim configuration like NvChad. NvChad is only a general configuration, so far it has nothing to do with a programming language.
3. Manually edit several lua configuration files;
4. Install the lsp's you need for each language, make sure to alter the lua config files to suit;
5. Install Treesitter, which give access to the AST, so the editor can show errors in real time;
6. Install Mason, which is a package manager that keeps neovim things up to date.

So all this is a bit of a pain, IMO. I learnt this from watching a YouTube video. Note that there are package manager instructions and pre built binaries, but these are only neovim itself, again nothing to do with a coding language.

Hence my wish for something more automated. Maybe I am doing it all wrong?

[keskiverto]

My bad. I did misinterpret your "pseudo-code".

The package manager (dnf) installs (RPM) packages.
A package provides files (executables, libs, config) and has dependencies.
The package manager ensures that all required packages are installed after package is.

For example, the EPEL has four packages that have "neovim" in their name:

# dnf -q --enablerepo=epel list \*neovim\*
Available Packages
neovim.x86_64                        0.8.0-0.el9              epel
neovim-ale.noarch                    3.3.0-1.el9              epel
python-neovim-doc.noarch             0.4.3-5.el9              epel
python3-neovim.noarch                0.4.3-5.el9              epel

I don't know any of them. The neovim-ale has description:

ALE (Asynchronous Lint Engine) is a plugin providing linting (syntax checking and semantic errors) in NeoVim while you edit your text files, and acts as a Vim Language Server Protocol client.

and requires neovim. The neovim requires luajit and other packages.

Therefore, installing neovim-ale will install neovim, but installing neovim will not install neovim-ale. The neovim-ale is an optional addon.

The ALE is an LSP?

One could create (RPM) packages for other LSPs and in them, or as separate package the rest of configuration (except the bits that are up to each user). A package for cmake LSP should probably require neovim and cmake packages.


The Mason is a conceptual problem. The idea of (dnf) managed packages is that the manager "knows" every file it has installed. If the Mason replaces files, then it "corrupts" the install made by dnf. All those "new neovim things" should be built into (RPM) packages and update installed with dnf, not Mason ...


What I do for "source installs" is to have then in entirely different subtree, apart from dnf-managed files and written by regular user, not root.


There are configuration management systems (e.g. Ansible, Chef, Puppet) that may help with those config file edits. As example, I have Ansible "playbook" that installs all needed RPM-packages and deploys all customizations to system config. That play is in Git repo(s), so there is both "backup" and history. Install of new machine is trivial.

[TheIdeasMan]

Hi and thanks for your replies.

Cheers, so I found those same packages, and installed them.

$ dnf -q list \*neovim\*
Installed packages
neovim.x86_64 0.10.4-1.fc41 updates
python3-neovim.noarch 0.5.2-2.fc41 updates

Available packages
neovim-ale.noarch 3.3.0-3.fc41 fedora
neovim-qt.x86_64 0.2.18-4.fc41 fedora
python-neovim-doc.noarch 0.5.2-2.fc41 updates

The linting seems to work, but there should be much more: sytax highlighting, code completion etc. So I gather these things are in the clangd lsp, see below the links I found.

So I am thinking it seems the main problem is that no one has made packages for specifically neovim cpp, so far as I can see. Which is surprising given that neovim is apparently one of the most popular editors for developers, and it ought to be possible to do it, as you have mentioned.

I did find these though:

https://clangd.llvm.org/installation
https://github.com/ProgrammingRainbow/NvChad-2.5

One can see how much file editing there is. At least these instructions are text based and all in one location, I will see how I get on.

Maybe there is a reason they do it this way? I guess that vi and vim users have always just edited files to configure things, but this seems conceptually a bridge too far - but not impossible, for me anyway. And it seems to me, the reason why we have package managers is to avoid a long multi stage manual process to install something.

keskiverto wrote:

The Mason is a conceptual problem. ...

I wonder about that too. I wonder about the scope of it: I am guessing/hoping it won't mess with compilers and cmake installations etc, just things that were installed by Mason to start with? I don't know. Maybe this whole methodology makes installation by package manager problematic, and that is the reason why no one seems to have done that?

[keskiverto]

Someone did wrote a news piece for April 1st about "one common package manager for all Linux distros". That was something one would want to believe, even when certain that it is impossible.

Python, R, LaTeX, you-name-it have their own. For application, agnostic of OS.
The Linux distro families have their package managers.
HPC likes and hates Spack https://spack.io/
Then there are containers, snaps, flatpacks, whatever.

For application developer it is easiest to hand out one something that "everybody" can use. E.g. container image. Building (and testing) for multiple targets is "extra work".

For user the easiest is if the package manager of their distro offers "point-and-click" install of all applications.

Maintainer of Fedora, EPEL, Spack, etc is a man in the middle who should (re)package the thousands of upstreams for their select distro. Neither of us wants to be that guy.


Python venv -- while I don't like Python -- at least puts all of that application in one place, which should be clearly apart from everything else (like files managed by dnf). The downside is that with N applications one might have something like 'numpy' N+1 times (in each venv and in system). Well, disk is "cheap".