Extension points

[marcopiraccini]

Not sure this is in the scope of this project (great idea, BTW), but I'd like to have a way to "extend" this concept more.
My point is: I use a slightly different set of tools, like nvim and sometimes atom. Or oh-my-ssh with zsh.
With current implementation, we have to use what is installed in the Dockerfile (we can customize only through docker-compose).

Obviously, I can install what I need just specifying a Dockerfile for my docker-compose that extends rylandg/myos:latest image. However, this still installs stuff I don't need (vim instead of nvim).
So wondering if we could have template docker-compose using a local Dockerfile in templates that can be customized, extending the base rylandg/myos:latest that would define only what is strictly necessary (e.g. SSH connectivity, user configuration). We might document how to extends for more common tools.

Again, this is probably out of scope for this project, so feel free to ignore this :).

[rylandg]

My point is: I use a slightly different set of tools, like nvim and sometimes atom. Or oh-my-ssh with zsh.
With current implementation, we have to use what is installed in the Dockerfile (we can customize only through docker-compose).

I believe nvim is nearly supported in the current version. Oh-my-zsh isn't shipped with the system, but I have an example in my personal dotfile repos of how to install a zsh library (I use zim for zsh).

https://github.com/rylandg/rylandg-myosfiles/blob/master/zsh/.zshenv

But those are practical answers. I want to address your much more fundamental question.

Obviously, I can install what I need just specifying a Dockerfile for my docker-compose that extends rylandg/myos:latest image. However, this still installs stuff I don't need (vim instead of nvim).
So wondering if we could have template docker-compose using a local Dockerfile in templates that can be customized, extending the base rylandg/myos:latest that would define only what is strictly necessary (e.g. SSH connectivity, user configuration). We might document how to extends for more common tools.
Again, this is probably out of scope for this project, so feel free to ignore this :).

This is not only "not out of scope" for MyOS, it's exactly the direction I want to take it. That being said, it's quite the optimization problem. Here's how I currently envision it

1. The core of the project is a highly optimized minimal Docker image which configures and installs universal dependencies. This probably means leaving out stuff like Vim, but raises a lot of questions. For example, the biggest dependency we currently have is python3. Vim8 requires python3 which might indicate it shouldn't be in the core. But what about all of the other things that need python3. At what point does python3 become "important enough" to warrant being in core. There is no right answer to this question, but we should define a set of rules and criteria so the selection process doesn't look unfair.

2. The project will have "layers". There are a few "classes" of layers that encapsulate different types of additions to the MyOS core. There might be an editor layer, shell layer, GUI layer etc etc. Remember, a core value of MyOS is the ability to quickly share environments. Layers reduce the chance that the majority of 1 users image differs from another users image. The ordering of layers needs to be determined along with the distinct layers that should exist. The goal would be eventually have myos-zsh-vim myos-zsh-emacs myos-bash-vim myos-bash-nano etc....

I would love to discuss this in more depth, as it really seems that you saw the core value of the product. Please let me know if this makes sense to you!

[marcopiraccini]

If I understand correctly, you are saying that here we should have a set of images reflecting the different combination of layers.

My point was slightly different. Let's say I want to use (and share) an environment which has zsh, nvim, nano, atom. So the layers I need, but for some reason I want 2 editors (nano and nvim).

Since every tool is actually related with a snippet of docker configuration, it's actually possible to compose this Dockerfile automatically (probably with some redundancy, but Ubuntu would not install dependencies twice) and simply use it in docker-compose. The limit of this would be that the image would be local and not published (publish it could be a further step).