Feedback, feature ideas, and installation issue

[codedbyistvan]

Hello,

First of all, thank you for this great project it is very well done, clean, and easy to use. Congratulations on the work you’ve put into it! 👏

I would like to share a few ideas and also report a small issue I encountered. I hope this feedback is useful.

1. Script execution feedback / logs
   Currently, when running a script, I can see on the dashboard that the script is “running,” which is helpful. As an improvement, it would be great to optionally have a pop-up or separate window showing real-time logs or execution feedback from the script. This would make debugging and monitoring much easier.

2. Shared scripts folder in the repository
   As a feature idea, it might be useful to have a dedicated folder in the GitHub repository for common or community-approved scripts. For example, I created a script that updates DeQ automatically, and I believe it could also be useful for other users. A shared space for such scripts could encourage collaboration.

3. Installation issue (minor bug)
   I noticed a small issue in the installation instructions. The steps mention downloading the archive, extracting it into a deq folder, and running the install script from there. However, after extracting the archive, there is an additional deq-files directory inside, so an extra cd deq-files step is required before running the installer. Clarifying this in the documentation would help avoid confusion.

Thank you again for your work and for maintaining this project. Keep up the great job!

Best regards

[deqrocks]

Hi @codedbyistvan

Sorry for the late reply. I didn't get any notification on this discussion and just saw it by accident.
Thanks for trying DeQ, I'm very happy about feedback.

1. Yes this was a thing when i implemented script execution and I wanted that feature too. Thing is not every script is easy to track. Some barely give any output, some run forever. Things like these sound like a trivial implementation at first glance, but you never know what people actually use it with. So in the end I decided that DeQ will listen for succesful or non-succesful execution. Everything else should happen in the terminal. Like debugging a script. So DeQ shouldn't be the tool to test your scripts with. You should make them stable and then run tem with DeQ.

2. That's a great Idea. But I don't know if scripts aren't too specific sometimes. Like hardcoded paths and everything? Not sure, but I'm willing to to create such a folder.
   Re your DeQ update script: great! I actually wanted to implement a auto-update mechanism, but this also isn't as trivial as it may seem and it would take quite a few lines of code to make this happen. I'm always happy when I can work around bloating the code. So yeah let's do that. I already added a community scripts folder to the repo. You'll find a (neccessary) contributions.md in there 👍🏻

3. Yep. I thought I fixed that everywhere but it seems i didn't. Will have a look now.

[codedbyistvan]

Hi, thanks a lot for the detailed reply and for taking the time to explain the design decisions. That all makes perfect sense.

1. Yes, I agree - having at least a clear success / failure status is already very helpful. And you’re right, DeQ shouldn’t be the place for script debugging; that should definitely happen in the terminal. The current approach is reasonable given how unpredictable scripts can be.
2. Thanks, I’m really glad you like the idea and even more that you already created the community scripts folder 👍In the meantime, I’ve prepared the update script and I’ll push it shortly so I can help kick things off with the first community script. Once you manage to implement a direct auto-update in DeQ itself, we can of course remove the script from there.
3. I see you already fixed the extra folder issue in the installation steps - awesome, thanks for the quick fix!

At the end, I also have a few more ideas for the future. Would you prefer that I continue them in this discussion, or should I open a separate discussion specifically for feature ideas?

Thanks again for the great project and for being so open to feedback!

[deqrocks]

Thank you and you're welcome!

Re the feature request: Whatever you like. I would say depends on how much complexity is involved. Jakob1379 chimed in below with another complex thing that is actually a bit off the original topic. Maybe it's better to make one or more new posts in the ideas section, then we can adress that one by one. Dunno! Your choice.

[jakob1379]

How come this is not a python package, that would allow you to integrate the installation into the main script pretty neatly

[deqrocks]

Good question! The single-file approach is intentional.
A Python package would add dependency management, virtualenvs, pip installs, potential version conflicts.

The install.sh handles systemd service creation, which is a one-time setup thing that doesn't need to live in the main script. Keeping them separate actually makes things cleaner.

The separation allows smart division of labor. For example, the recent auth feature uses shell-based crypto (openssl) during install for password hashing and secret key generation. The Python code just validates at runtime. No crypto library needed, keeping server.py lean. The pattern works for any "run once at setup" vs "run constantly at runtime" split.

This means: Just a file that runs. No dependency management.

[jakob1379]

I agree with the single-file philosophy, but the current approach still makes implicit assumptions (Python version, interpreter availability, PATH, etc.). You can keep “one file” while improving quality/safety and making those assumptions explicit—without turning it into a full package.

A good middle ground is uv’s inline script metadata (similar to “requirements” in bash docs). It documents the required Python version and dependencies in the file itself, and lets uv select/provision a compatible interpreter rather than relying on whatever happens to be installed on the host (Ubuntu often has one system Python; on Windows it may be absent or mismatched).

Example:

# /// script
# requires-python = ">=3.12"
# dependencies = []
# ///
def main() -> None:
    print("Hello from server.py!")

if __name__ == "__main__":
    main()

Then users can run:

• uv run server.py (reproducible interpreter selection, requirements are self-documenting)
  while still allowing:
• python server.py (best-effort, but at least the contract is written down)

[deqrocks]

I appreciate the thought, but DeQ genuinely has zero dependencies. The "contract" is already as simple as it gets: Python 3, Linux, SSH. That's documented in the README. So maybe I'm not getting your idea, but isn't that trying to solve a problem DeQ actuall doesn't have?
Adding uv metadata would require users to install uv to gain... nothing. We'd be adding a tool dependency to manage zero dependencies.
If someone's Python is so broken that python3 server.py doesn't work, uv won't save them. And if their system is healthy, uv adds friction for no benefit.
The current approach "just works" on any Linux with Python 3. That's the goal.

[jakob1379]

I think there are a couple of things that could lower barriers to adoption here.

Even with a single-file philosophy, there's an opportunity to make the setup more straightforward. Currently, running the script assumes quite a bit about the environment, which might catch new users off guard. Here's what I encountered:

❯ python server.py
/home/jsg/Documents/forks/deq/server.py:6253: SyntaxWarning: invalid escape sequence '\.'
  const name = inputs[0].value || checkbox.dataset.name.replace(/\.[^/.]+$/, '');
Traceback (most recent call last):
  File "/home/jsg/Documents/forks/deq/server.py", line 449, in <module>
    ensure_dirs()
    ~~~~~~~~~~~^^
  File "/home/jsg/Documents/forks/deq/server.py", line 413, in ensure_dirs
    os.makedirs(DATA_DIR, exist_ok=True)
    ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen os>", line 228, in makedirs
PermissionError: [Errno 13] Permission denied: '/opt/deq'

Two specific suggestions:

1. Using XDG Base Directory paths for config and data would let deq work without elevated permissions across different Linux distributions. You can implement this with the standard library using os.getenv with fallbacks for $XDG_DATA_HOME (defaulting to ~/.local/share/deq) and $XDG_CONFIG_HOME (defaulting to ~/.config/deq). This keeps the single-file approach with zero external dependencies while respecting where users expect their data to live.

2. Adding inline script metadata (uv's # /// script blocks) would make Python version requirements explicit and help with reproducible interpreter selection, even if you stick with the single-file approach.

Neither requires packaging or changing the single-file philosophy, but both would make it easier for people to try deq without friction. And don't get me wrong, I love DeQ, hence i want it to be as easy as possible for people to use it.

[deqrocks]

Hi Jakob,

Thanks dor diving into the code and trying to make DeQ more accessible.

Fair point on the error message. But this is expected: DeQ is designed to be installed via install.sh, which creates /opt/deq and sets up the systemd service. Running python server.py directly without install will fail.
The README documents: download, unzip, run install.sh. That's the supported path.
XDG paths would make sense for a user-space application, but DeQ runs as a system service with root access (for SSH, WoL, shutdown commands, etc.). Scattering config across ~/.config doesn't fit that model.
The SyntaxWarning is valid though, I'll fix that escape sequence. Thanks for catching it.

[jakob1379]

Right, I forgot about those features. Thanks for spending your time to answer my questions and thoughts! I really appreciate it.