[Feature] Install Instructions for non-docker environments

[brad-charboneau]

Is your feature request related to a problem? Please describe. No

Describe the solution you'd like I simply want bare metal install instructions so that those of us using LXC Containers or VMs can install without docker.

Describe alternatives you've considered I have not considered other options

Additional context Myself and many others use Proxmox as a hypervisor and would like it if a solution can be provided to use native capabilities rather than nesting virtualization layers. since Baremetal instructions work the majority of the time for building out LXC Containers this would be beneficial. If I have a detailed set of instructions I can likely script it out and create a pull request to include in your repo, if desired.

[zurdi15]

I don't think we are going to support a bare metal installation officially. The closest thing you have to acomplish such task is to follow the DEVELOPER_SETUP and maybe the dockerfile if you want to check what's done inside to build the image.

[dotbanana]

If I have a detailed set of instructions I can likely script it out and create a pull request to include in your repo, if desired.

If you fork this for bare-metal please leave a link here.
I also would be very interested.
The fact that devs pack all stuff behind this abstraction layer and people basically use bundled server-software like compiled binaries in the beginning of windows-time is concerning at best.

Addendum:

As JFrog security researchers found, around 20% of the 15 million repositories hosted by Docker Hub contained malicious content, ranging from spam to dangerous malware and phishing sites. https://jfrog.com/blog/attacks-on-docker-with-millions-of-malicious-repositories-spread-malware-and-phishing-scams/

[adamantike]

The main reason for declining some of these requests, is not that open source maintainers are lazy, evil, or stupid to not understand the benefits of what's being proposed, although that seems to be the general reaction in some of these issues.

Trying to support every possible deployment mechanism, means that the maintainers will need to spend a lot of time and effort, for stacks they don't even use, to debug and fix issues when the contributor that implemented this "simple" requirement is no longer around. So is it better to accept the proposal, and revert it back when it becomes abandoned, unsupported, and with users asking for assistance?

The project has a very small number of contributors, so I encourage you to join the community, and start small by checking out what regular users are actually having issues with or waiting to be implemented.

[dotbanana]

Trying to support every possible deployment mechanism, means that the maintainers will need to spend a lot of time and effort, for stacks they don't even use, to debug and fix issues when the contributor that implemented this "simple" requirement is no longer around.

I would understand such an answer when we would be talking about some niche feature that has to be implemented first, but the python & shell-code is already there.
With asking for this tool without Docker I am not wanting to make it more complicated, but actually more easy. In most other projects you have source code and no Docker-Container.
A Docker is then often created by third party who maintains it then on Docker-hub for the casuals.
But you've made it the other way around somehow and you actually convinced yourself that this is normal and more easy. This is not normal and more easy.
This is just lazy and bad practice.