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.