Open adamcooke opened 3 years ago
Is there a particular reason as to why the next version of Staytus must be in Docker? In my use case, my Staytus instance runs using Phusion Passenger, which is a module for Apache [httpd 2.4]. Therefore, I don't use Procodile to run a webserver instance for it. Running Staytus inside docker is not practical, due to the virtual server being set up to work only with a non-docker environment.
I would hope that there would be a way to run Staytus without having to be forced to using Docker though, especially as my compute server doesn't have the RAM capacity to run a virtual machine within an existing virtual machine and it would require all sorts of changes to make Phusion Passenger work with a service inside of a docker instance.
Is there a particular reason as to why the next version of Staytus must be in Docker?
The maintenance burden for me to support installing it in unknown environments is primary driver. In order to ensure timely updates, I need to make it as easy as possible to develop and distribute. However, I don't have any plan to do anything that'll stop Staytus working using whatever means you feel most appropriate. If you want to clone the repo, checkout a tag and run it on Passenger, that's fine but you'll need to configure all that yourself (like you're doing already).
Is there a particular reason as to why the next version of Staytus must be in Docker?
The maintenance burden for me to support installing it in unknown environments is primary driver. In order to ensure timely updates, I need to make it as easy as possible to develop and distribute. However, I don't have any plan to do anything that'll stop Staytus working using whatever means you feel most appropriate. If you want to clone the repo, checkout a tag and run it on Passenger, that's fine but you'll need to configure all that yourself (like you're doing already).
Okay fair enough yeah. As you rightly indicated, I simply clone the repo and then run the appropriate bundle/exec commands and then register the app in Passenger which works fine for the moment, and as long as that continues to be possible, I'll be 👍 with that. Thanks for the reply!
Any progress so far? ;-)
@adamcooke first of all thanks for this great tool :bow: I am wondering what is the maintenance state of the project at the moment ? I have some fixes I had to do in my fork that could be interesting to upstream but as I don't see much activity I'm wondering if it's worth spending time exctracting those. I also noticed I did some of these changes (like moving the themes to app/assets and finishing the rails 5.2 upgrade) before reverting back to your master version in order to reduce the diff and ease merges, but I don't know if that was a good idea or not. Shall we expect more updates on your end? Are you still using it? Are you interested in PR about this? (e.g. Minor fixes, rails updates, more tests, fixing deprecation warnings, using activejob for easier deployment, etc...) Are you looking for help maintaining it?
Thanks and have a great week!
Hi @jarthod - I'm still keen do some work on Staytus, I just need a bit of time to sit down with it. We use it where I work so still very much in use. I can't promise anything at the moment but I do hope to have some time to look at it properly in the next couple of months.
@adamcooke ok thanks for the quick response, glad to hear that :) And so as you were in the middle of a big refactoring, would you be happy to receive (and able to handle) some PRs now or would you prefer to finish up on your end before accepting more contributions? I can wait for your cue :)
I'm giving Staytus a bit of an overhaul. This branch will be following those changes. The key things that I'm looking to introduce during this are relatively minor from a UI point of view by huge from actually running the application.
Staytus will only support using containers to run it. I will provide containers and full documentation on how to run Staytus. Similar to work I've recently done on Postal.
The concept of having multiple themes will go away. Instead, the default theme will move back into the application but will allow users to override any part of it themselves by placing appropriate template files in the
content/views
directory. This will be more compatible with running Staytus in a container.Outstanding issues and PRs will be closed or merged as appropriate.
A new documentation site will be established at
docs.staytus.co
.A new HTTP API will be added (powered by Apia and documentation published).
Staytus 2.0 will be released to include these change. The current version of Staytus in the
master
branch will be frozen because some people have installed Staytus by checking out this branch. A newmain
branch will be established to track all future changes.