Declarative way of mapping groups to hosts

[TeeWallz]

Hi,

Pacdef is applying a declarative approach to package management -- a method I prefer without the overhead of NixOs.

However to actually apply the configs to a machine in Pacdef, one needs to imperatively run 'import' to apply the config to a machine from my understanding, using a symlink as the way to link a group to a host. If these symlinks are lost, the desired state is lost. This would then need an imperative script overlayed on top of pacdef to create reproducible builds and ensure state.

EDIT: (Upon looking at this, pacdef group new test already outputs to config/pacdef/groups/, which creates a non-symlink already, breaking what seems to be the best practices the project is after - and making the current host use all newly created groups by default). What is the desired workflow, i.e. a basic 'test_run.sh)? Is it pacdef create -> cut files into git dir-> import/symlink back again? )

Is there a way to apply the groups to a host via the config, it to detect the current host (like Ansible) , i.e.

cat hosts/host1 [group1] [group2] [package2]

hosts/host2 [group2] [group3] [package1]

and enable the ability to run :

git clone <config>
# [No imports]
pacdef sync

I understand there is currently 'hosts' directory for host-specific packages, but if there are overlaps you'd have to duplicate package groups

Is this something that is already done, or this package has an appetite for if not present?

Thanks for the package, Love your work! : D

[steven-omaha]

Hey, thanks for the ideas and the request. Well thought out and well written! Also thanks for the words of appreciation! :)

In short: I would like to not implement this in pacdef, for a couple of reasons. Let me explain in detail.

If these symlinks are lost, the desired state is lost. This would then need an imperative script overlayed on top of pacdef to create reproducible builds and ensure state.

That is correct if you use pacdef exactly as it was written in the README. But that's merely an idea to get people started, because most people are not too familiar with the declarative approach to package management. I'm interested in seeing people coming up with their own creative ideas to use this tool.

So far I have a single pacdef group repo where I can mix and match group files for each machine. I just pacdef group import whatever I want. Your argument is that the state of each machine is not reflected in a declarative manner. Here's what I would do about that.

• Have your group files in your dotfiles repo, in whatever structure you want
• for each host, create a directory in the repo, let's say myhost
• in the host-specific dir, create a symlink to wanted group files. Then the state of the host is stored in the repo
• then you can pacdef group import myhost, which imports the outer level. Since #27 pacdef will traverse imported folders and use every group file it can find in there.

Or you could, as your said yourself, have another declarative tool to associate the group files with each host. But IMO that is out of the scope of pacdef. I would like to follow the Unix philosophy of "doing one thing and doing it well" and avoid feature creep to some extent.

Or you could write your own declarative dotfiles manager (which I did), or you could use Ansible, ...

Upon looking at this, pacdef group new test already outputs to config/pacdef/groups/, which creates a non-symlink already, breaking what seems to be the best practices the project is after - and making the current host use all newly created groups by default)

Correct. I came up with that when I would like to try something that involves completely different toolchains. Say I want to try something in javascript, then I would pacdef group new -e js, put all stuff in there, sync it. Then I find out something is missing, I can add it. Since I have the symlink warnings enable, it will remind me to store the group file somewhere else. So this is for rather temporary things.

What is the desired workflow, i.e. a basic 'test_run.sh)? Is it pacdef create -> cut files into git dir-> import/symlink back again? )

So some kind of pacdef group export <...> would be great as an add-on, which should mv the group file and then reimport it. That could be valuable for the tool.

[steven-omaha]

Group export is now implemented

[TeeWallz]

Thanks for the write up

I appreciate you spending your time posting your thoughts on the scope and feature creep of the project and where it sits in the ecosystem. It's awesome to see a project with firm boundaries on what it sees itself as.

I'll continue to use an external tool to manage the declarations of groups to a host and will post any further bugs I find

Thanks again :D

[coopbri]

Hey @steven-omaha, I am evaluating pacdef right now (looks awesome, exactly what I was looking for for package management) and am considering migrating from a Nix w/ Home Manager system. You mentioned above "you could write your own declarative dotfiles manager (which I did), or you could use Ansible" -- would love to hear if you have any leads into if this dotfiles manager is a public project or how you did this. I wasn't a fan of yadm, stow, bare git repo, etc. for managing dotfiles which led me to just adopting Home Manager so I could manage things declaratively, but I'd rather move away from the Nix ecosystem, just not a fan of the language nor workflow experience. I also took a quick look at https://github.com/SuperCuber/dotter which seems promising. Cheers!

[steven-omaha]

@coopbri My manager is not public, unfortunately. It works roughly like this.

1. Have a JSON file that is a list at the outermost level. Each item in the list is a tool that requires some kind of dotfile
2. For every item, provide conditions for when it needs to be installed. I use a mix of hostnames and OS for this. Check the hostnames / OS for which the tool is required against the one of the machine. Install it if it matches
3. Create symlinks for each applicable tool from the dotfiles repo to the config dir.