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.