Anarchy's project goals

[Segdon]

As stated elsewhere; it could be a good idea to formulate some goals and guidelines for the future of the project.

Code

• following KISS principles
• readable and well commented code
• POSIX compliance

Project

• Simplicity (KISS)
• modularity (scripts work independently of each other and use positional arguments)
• container compatibility - being able to compile anarchy in containers
• a way to be able to just download the archive and run anarchy on existing isos
• we should add unit tests so we can check if the scripts work as intended
• we should make it idempotent, and by that I mean even if we completely stop the development, users should still have 100% functionality even after a long time. No non-existant packages and such [0]

[0] Which means manually compiling yay during the installation and updating keys and package lists

[erazemk]

@Segdon Do you have any suggestions?

[Segdon]

Some questions first containter compatibility -> docker and such? POSIX compliance -> is this difficult? what are unit tests?

[Segdon]

Although I understand Kostas point on not burdening the installer to much with our own customized material, i think i would be a good idea to add a feature to import some dotfile configuration from (possibly a separate) git. or in the form of a post-install-script

[erazemk]

containter compatibility -> docker and such?

Yup, Docker and/or OSI (standardized) container images. This would make it much easier for users to compile it by themselves and wouldn't require any dependencies installed on the host system (the one you'd be compiling on).

POSIX compliance -> is this difficult?

Yeah, I'd say so, so it would take a while, but we can update the scripts one by one. Also POSIX-compliant scripts don't use arrays, which we can solve by adding packages directly to the file instead of adding them to an array and then adding the to the packages file at the end.

what are unit tests?

They're a way to test separate parts of a product/software. E.g. each unit test runs a script and checks if it executed correctly, which should minimise bugs that users find.

[Segdon]

Maybe there should also be a kind of prioritization in the objectives.

I would upvote -following KISS principles -readable and well commented code -modularity (scripts work independently of each other and use positional arguments) -we should make it idempotent, and by that I mean even if we completely stop the development, users should still have 100% functionality even after a long time. No non-existant packages and such -add unit tests so we can check if the scripts work as intended

I would downvote -POSIX compliance -container compatibility - being able to compile anarchy in containers -a way to be able to just download the archive and run anarchy on existing isos

[erazemk]

Although I understand Kostas point on not burdening the installer to much with our own customized material, i think i would be a good idea to add a feature to import some dotfile configuration from (possibly a separate) git. or in the form of a post-install-script

I actually thought about this. If we could find a dotfiles format that would work, we could completely remove the customised desktops from the installer and make them optional through the use of dotfiles.

So +1 for this idea.

[erazemk]

Maybe there should also be a kind of prioritization in the objectives.

I would upvote -following KISS principles -readable and well commented code -modularity (scripts work independently of each other and use positional arguments) -we should make it idempotent, and by that I mean even if we completely stop the development, users should still have 100% functionality even after a long time. No non-existant packages and such -add unit tests so we can check if the scripts work as intended

I would downvote -POSIX compliance -container compatibility - being able to compile anarchy in containers -a way to be able to just download the archive and run anarchy on existing isos

Sure, that sounds fair. Although if somebody decided they wanted to work on a specific feature/objective I'm all for it.

[erazemk]

One not really code-related goal is that after the refactoring is complete and the code is fairly stable, we should work on promoting Anarchy a bit, because getting new contributors could really help the project.

[Segdon]

Although I understand Kostas point on not burdening the installer to much with our own customized material, i think i would be a good idea to add a feature to import some dotfile configuration from (possibly a separate) git. or in the form of a post-install-script

I actually thought about this. If we could find a dotfiles format that would work, we could completely remove the customised desktops from the installer and make them optional through the use of dotfiles.

So +1 for this idea.

I like the way manjaro did this: https://github.com/manjaro/desktop-settings They implement 'skel' files for their community edition

[Segdon]

One not really code-related goal is that after the refactoring is complete and the code is fairly stable, we should work on promoting Anarchy a bit, because getting new contributors could really help the project.

Sound great; stuff for a new issue ;-)

[erazemk]

What is your opinion regarding removing customised desktops, so we don't have to maintain them and possibly either completely removing other desktops or preferably allowing DEs as they are now, just not the customised ones.

Customisations could maybe still be set up with dotfiles, but someone would have to implement and maintain this.

This change would also move us closer towards our KISS goal.

[Segdon]

I think this is the best way forward. One might dream, but i don't suppose this project will ever have a whole army of dev's to maintain stuff, nor does it necessary need it. A low maintenance, but well running install-script feels like the way forward. What i would propose though is a (optional) build-in way of easily pulling dotfiles during installation. Be it bare or yadm or stow or whatever. That way users can share their setups for those still looking for a customized desktop. I really like the way luke smith does it in his installer. (github/lukesmithxyz/larbs) Especially the installing a customized list of programs from a selfhosted csv-file. Come to think of it, his whole project is like a post-install-script. Maybe we can figure something out like this that is standardized yet flexible (appealing to all little separate scripts perhaps?) That way it can grow at the pace that we want/is feasible and be yet easy to maintain separate from the installer-project?

I don't really now how close this way adheres to the KISS goal, but it is a way to make a project appealing to both experts and medium-skilled people, without the maintenance of customized desktops.

[erazemk]

I like Luke Smith, but I don't think the larbs approach would be good for Anarchy and it would add unnecessary complexity.

Also by allowing just any dotfiles format (e.g. stow, plain git repo, yadm and such) we would again be increasing the complexity and would have to add support for all those formats. And even if we somehow manage to do that, users will want more formats.

Currently I think the most KISS-oriented and easiest to implement option would be to just not add a custom dotfiles option and expect the user to add their own dotfiles after the installation. This way everyone can choose whichever format they prefer and there is no additional maintenance cost for us.

The other option would be to focus on one of the implementations (e.g. only officially supporting bare git repos) and allow that. But even this would add unecessary complexity that we don't need.

Since this is not a priority I won't focus on it now, but in the long run we should discuss how this should work. Realistically I believe the one option approach is the most we can do, because supporting multiple options is way to much of a burden.

[Segdon]

Currently I think the most KISS-oriented and easiest to implement option would be to just not add a custom dotfiles option and expect the user to add their own dotfiles after the installation. This way everyone can choose whichever format they prefer and there is no additional maintenance cost for us.

I think this is self-evident. In a way, the choice for a KISS option closes this whole debate, because it means there is only one thing anarchy should do well, and that is installing. On the other hand, a standardized way to implement one's configuration in one go and not do the burdensome setup every time feels also very KISS :-)

I'm not arguing for doing this all by ourselfs (or by yourself more correctly), just to provide an standardized way for others to hook on to, if this doesn't sound to far-fetched

Since this is not a priority I won't focus on it now, but in the long run we should discuss how this should work.

Off course this isn't a priority. I think the most important thing now is to ditch all the customization (and maybe DE and WM altogether) for now till you rebuild is ready. Once that base is ready and well tested, we (read = you) can add to our heart's content...

I believe the one option approach is the most we can do, because supporting multiple options is way to much of a burden.

what is your view of that one option then? the bare git?

[erazemk]

On the other hand, a standardized way to implement one's configuration in one go and not do the burdensome setup every time feels also very KISS :-)

There is no standardized way for deploying dotfiles.

just to provide an standardized way for others to hook on to, if this doesn't sound to far-fetched

This is what an API is, and I don't want to limit people's configurations by forcing them to use something like this even more than I don't want to implement an API - that would stray far more into the non-KISS direction than just allowing one of the deployment options.

I think the most important thing now is to ditch all the customization (and maybe DE and WM altogether) for now till you rebuild is ready. Once that base is ready and well tested, we (read = you) can add to our heart's content...

I agree.

what is your view of that one option then? the bare git?

Bare git sounds like the most likely candidate to me, since git is usually already installed and doesn't require any dependencies. This would also simply the installation since all that would need to be done would be to clone the repo.

Stow would be another option, since it's just one dependency, but the problem is we'd have to parse all the directories to install the files. Just cloning the repo wouldn't help much in this case.

I have no idea how we could go about implementing other options.

Regarding the standardized way though: We could make it so that users can choose any deployment option they want and if we find something like a .anarchy-dotfiles.sh file in the root of the repo, it will be run when cloning the repo. This way users can specify whatever deployment option they want.

The file would just be a standard bash script, which the users would customise (they'd list the commands they want run, like symlinking or stowing).

What is your opinion on this? Is this the hook you were talking about?

[Segdon]

There is no standardized way for deploying dotfiles.

for sure, but we can choose one, that then being the standard for installing on top of the anarchy installation I think my prefrence would also be a bare git, for the reasons you list.

What is your opinion on this? Is this the hook you were talking about?

If i understand it correctly, this would be a script that adjust the user configuration, during install, with the deployment-option (stow, yadm, bare git, ...) of their choice? Aren't we back at a higher complexity-level, that way? Or is it just that the installer executes anarchy-dotfiles.sh whenever it finds it, and it's up to the user to input a well-working script in it?

[erazemk]

Or is it just that the installer executes anarchy-dotfiles.sh whenever it finds it, and it's up to the user to input a well-working script in it?

Yup, it would just execute the script. If there is no script found Anarchy would clone the repo so there is no extra work for existing bare repos. This way every user can configure their dotfiles the way they like and as long as the script works fine without any extra parameters, then the deployment should work perfectly.

This would possibly also open up the option of users submitting their dotfiles and we could list the urls somewhere on the wiki. This could also possibly replace the existing customised desktops, since using the script extra software currently installed when selecting a precustomised DE could also be installed, making everything even more modular.

[Segdon]

then I would advocate also an install-this-list-of-software.sh file

This would possibly also open up the option of users submitting their dotfiles and we could list the urls somewhere on the wiki. This could also possibly replace the existing customised desktops, since using the script extra software currently installed when selecting a precustomised DE could also be installed, making everything even more modular.

I think that this is somewhat what I had in mind

Glad we agree

[erazemk]

then I would advocate also an install-this-list-of-software.sh file

The list of software should be a part of the .anarchy-dotfiles.sh file, not a separate one, since it won't be necessary for all dotfiles. The package installation code can easily be added to the end of the file, no need to split it into two files.

[Segdon]

That's settled then! :-)