Forem: Dimitrios Desyllas

How I can perform spellcheck in a TkInter Entry:

Dimitrios Desyllas — Tue, 10 Mar 2026 17:12:33 +0000

Mar 10 '26 Comments: 1 Answers: 1

I made this type of input:


class PasteableEntry(tk.Entry)
    def __init__(self, master=None,initial_value:str="", **kwargs):
        super().__init__(master, **kwargs)
        self.initial_value = initial_value
        self.insert(tk.END, self.initial_value)

        # Clipboard bindings
        self.bind("<Control-c>", self.copy)
        self.bind("<Control-x>", self.cut)
        self.bind("<Control-v>", self.paste)

        # Undo binding
        self.bind("<Control-z>", self.reset_value)

        # Border
        self.configure(highlightthickness=2, highlightbackground="gray", highlightcolor="blue")

    # --- Clipboard overrides ---
    def copy(self, event=None):
        try:
            selection = self.selection_get()

…

Open Full Question

As I ask in question above I am looking for an apprkach on how I can spellcheck an tkInter entry. I am building a whatsappo template manager and I want to be able to spellcheck my inputs.

Can you reccomend me an approach?

Why I am unable to close the A Tkinter frame and create another one?

Dimitrios Desyllas — Wed, 04 Mar 2026 17:20:00 +0000

As I ask upon:

Mar 4 '26 Comments: 2 Answers: 1

I made this tkinter app:

import os
import tkinter as tk
from tkinter import ttk
class SelectBodyScreen(ttk.Frame):

    def __init__(self,root, lang, prod_text,test_text, on_next):
        super().__init__(root)

        self.lang = lang
        self.prod_text_content = prod_text
        self.test_text_content = test_text
        self.root = root

        self.build_ui()
        self.on_next = on_next

    def next_clicked(self):
        selected_body = self.final_text.get("1.0", tk.END).strip()
        self.on_next(selected_body)

    def use_prod(self):
        text =

…

Open Full Question

I am making a wizard where it generated a frame whilst closes another one upon next using Tkinter.

My issue is that the frame is improperly closed as you can see upon:

Developing locally an aws lambda

Dimitrios Desyllas — Wed, 24 Sep 2025 17:52:32 +0000

The problem (as always)

In my career, I’ve often seen AWS Lambdas deployed directly without the source code being committed to GitHub. Even worse, many projects lack a defined architecture or tooling that allows testing Lambdas locally before deployment.

Here, I’ll walk through how to introduce some basic tools to fix this.

Setup aws locally

To run and debug Lambdas locally, we need an execution environment that mimics AWS services. For this, I recommend using LocalStack with Docker:

services:

    localstack:
      image: localstack/localstack
      ports:
        - "4566:4566"
        - "4510-4559:4510-4559"
      environment:
        - SERVICES=lambda,logs
        - DEBUG=1
        - LAMBDA_EXECUTOR=docker
        - DATA_DIR=/tmp/localstack/data
        - AWS_DEFAULT_REGION=eu-north-1
        - LOCALSTACK_API_KEY=${LOCALSTACK_API_KEY-}
        - USE_SSL=false
      volumes:
        - "./localstack/volume:/var/lib/localstack"
        - "/var/run/docker.sock:/var/run/docker.sock"

There are 2 things you need to keep notice:

Upon SERVICES environmental variable we need to define 2 services:
- lambda that indicates we need to use localstack for lambda execution.
- logs in which any log outpud of the lambda would be outputed into stdout. This is the equivalent of cloudwatch service.
We have disabled ssl upon USE_SSL
The spawned container need to communicate with docker in order to run the lambda. For this we need to define:
- LAMBDA_EXECUTOR as docker
- Map the docker socket file inside the container via a bind-mount. It is achieved via putting /var/run/docker.sock:/var/run/docker.sock upon volumes section.

Localstack is available thorugh http://localhost:4566 as defined upon:

  ports:
        - "4566:4566"

Download Lambda code

Lambda code is usually stored as a .zip file, which contains both the application code and its dependencies:

Detect lambda entrypoint

Lambdas are node.js or python scripts, usually is is a function inside a specific file.

For example, in a Python Lambda, the entrypoint is often defined as file_name.handler_function:

In this case, AWS starts execution from the lambda_handler method inside lambda_function.py:

Identifying the entrypoint is crucial because it helps determine dependencies and setup.

Installing the Required Python or Node.js Version

AWS Lambdas run with specific Python (or Node.js) runtimes (e.g., Python 3.9, 3.10).

You can check which runtime is being used under the Code tab in the AWS Lambda console:

Organizing Code and Dependencies:

Once you’ve downloaded the Lambda .zip, unzip it into a working directory. I recommend creating two folders:

Original Lambda → The raw contents of the .zip. (for example my-lambda-orig
Clean Repo → A structured project where you separate code from dependencies. (for example my-lambda). Thefollowing stricture is reccomended:
- src -> containing lambda source code
- tools -> for usesfull tools

Why separate them?
AWS often packages Lambdas with both source code and dependencies. Instead, you’ll want to manage dependencies with pip (and later, requirements.txt/poetry/pipenv).

Here’s the process:

Copy the main Lambda file (e.g., lambda_function.py) into ./src.
Inspect the start of the Lambda file (e.g., lambda_function.py). There you can distinguish which files are needed ans which are 3rd party libraries. Any non 3rd party library copy them upon src folder of the clean repo.
Using the name you can detect which ones are 3rd-party and which ones are required. It is a good idea to keep a list with 3rd party libraries as well.
Copy only the application code (your .py files) into the clean repo.

A common Library is the boto one which is used for interfacing with AWS itself.

Once seperate the code init git and fo a first commit:

git init
git commit -m "Cleaned Code"

Create a virtualenv

We need to have a list with lambda dependencies for that we ned to initialize a virtual env:

python -m venv ./.venv
echo ".env" > .gitignore
git add .gitignore
git commit -m "Ignoring virtualenv"
source .venv/bin/activate

Then using pip install we are installing the nesesary dependencies, for example for boto we run:

pip install boto3

Once depencendies installed we need to keep them into a list for that we need to run:

pip freeze > ./requirements.txt
git add requirements.txt
git commit -m "Added Dependencies"

Now every time we need to install them we can do:

pip -r requirements.txt

Detect environmental variables

Lambas also retrieve settings externally from environmental variables. For pythonk lambdas scan for strings such as os.environ.get(, the parameter passed contains the environemtnal variable required.

Deploy upon localstack

Now that we have code sorted out we can create a lambda into localstack. For this we need to package the lambda as a new zip:


## Package lambda

mkdir package
echo "package" >> .gitignore
git add .gitignore
git commit -m "Ignoring support folder for packaging"

# Copy code
cp -r ./src package/

# Install dependencies upon package folder
pip install -r requirements.txt -t package

#  Zip package
cd package
zip -r9 function.zip 
cd ../

# Package folder is temporary
rm -rf ./package

The commands above do 2 things:

Create a intermediate folder where code is staged, the folder is named package. This folder and it should be ignored from git.
Copy all lambda source upon package folder. keep in mind we need to copy the contents of src and not the src itself.
Install all dependencies at package folder. This is achieved via providing the folder name upon -t parameter.

The method described above can also be used for packaging the lambda for production as well. The zip file can be uploaded, thus replacing the lambda code.

Deploy on locakstack

For this we can run:

   aws --endpoint-url=http://localhost:4566 lambda create-function\
    --function-name "my-function" \
    --runtime "python3.9" \
    --role "arn:aws:iam::000000000000:role/lambda-role" \
    --handler "python3.9" \
    --zip-file "fileb://function.zip" \
    --environment Variables="{VAR1=\"Hello\"}"

This command above creates the function my-function this is the lambda function we need to create. At the command above we need to pay attention upon some arguments:

--endpoint-url In our case we need to provide it with the localstack setup. If not it will try to create the lambda upon actual aws. In out case this si not desirable
--fucntion-name a distinctive function name. Each lambda should have its own
--role Keeping the value arn:aws:iam::000000000000:role/lambda-role is fine on every time tyou crreatr a new lambda. Localstack does not check for roles but we need to place this in order to avoid any unwanted behaviour.
--handler: Place the one that actual lambda upon aws uses. Here we define what would be used for lambda execution.
--zip-file The file we created containing code + dependencies.
--environment If no environmental variables used, ommit it. The value is a string encloded in {} having this format (do not confuse it with json):

    {VARIABLE_NAME=VALUE,VARIABLE_NAME2=VALUE2}

Develop and redeploy

During development if a changes is needed you need to re-package the lambda. Re-creating is not needed unless localstack container is terminated.

Updating the code is done like this:

aws --endpoint-url=http://localhost:4566 lambda update-function-code --function-name "my-function" --zip-file "fileb://function.zip"

Whilst if environmental variables need to change you can do it like this:

aws --endpoint-url=$ENDPOINT lambda update-function-configuration \
    --function-name "my-function" \
    --environment Variables="{VARIABLE_NAME=VALUE,VARIABLE_NAME2=VALUE2}"

Misc tips

If an extra dependency is needed is it a good idea to enable the generated virtual environment, then install it via pip. Then update the code upon localstack as mentioned above.

Create a Pull request into another repository using github actions.

Dimitrios Desyllas — Fri, 05 Sep 2025 21:40:38 +0000

Upon developing the mkdotenv project I hgad this partucilar problem. I needed to release upon mac as well and for that I need a repo that hosts the homebrew tap.

The procedure I developed is the following:

Upon mkdotenv actions create the homebrew tap
Clone homebrew repo
Create a branch and copy the file into Formula folder
Test that app is installed
push the branch
Create the PR

The last steps was the one that caused me pain therefore I would explain what I did to solve it.

Required apps and settings I needed to install

Step1 Install Qoomon Access Tokens for GitHub Actions

I used the qoomon/actions--access-token project, that provided me a GitHub App that can issue temporary tokens during a workflow run. These tokens are powerful because they can grant fine-grained permissions such as pushing branches or opening PRs across repositories — something the default GITHUB_TOKEN cannot always do. Also it is a better alternative than storing PAT upon secrets as well.

In my case I installed it from Marketplace. Setup is free, but since it’s an app install, but I needed to go through the standard GitHub "purchase" flow (at $0), that required meto provide some basic private info (name and address mostly).

Once the app is installed, I had to define token policies using YAML files. There are two levels of configuration:

Global policies (.github-access-token repo)
You create a dedicated repository named .github-access-token.
Inside it, you add an access-token.yaml file that defines the general rules: which repositories can request tokens, and what operations are allowed.
Think of this as your organization-wide or user-wide "master policy".
👉 Example: my .github-access-token repo
Local policies (.github/access-token.yaml in a repo)
Inside each target repo (the one you want to push to or create a PR against), you also create a file at .github/access-token.yaml.
This file must match the owner of the global repo above and acts as a per-repository confirmation.
It narrows down the rules from the global file to the specific repository, making sure you explicitly allow those actions in that repo.

In my case I have 3 repos:

pc-magas/.github-access-token in which I have the general policies of allowed action upon access-token.yaml in it
pc-magas/homebrew-mkdotenv The homebrew tap in which pr's would be autogenerated
pc-magas/mkdotenv in which:
1. Formula file is created
2. Github action create and push a branch upon pc-magas/homebrew-mkdotenv with the new formula
3. A pr is created

As you notice all of them are owned by pc-magas.

The general flow goes as follows:

+---------------------------+                  +-----------------------------+
|   pc-magas/mkdotenv       |                  |  pc-magas/homebrew-mkdotenv |
|  (creates formula)        |                  |  (receives PRs)             |
|                           |                  |                             |
|  GitHub Action runs --->  |  ----push---->   |   Branch created            |
|                           |                  |   PR opened                 |
+---------------------------+                  +-----------------------------+
             |                                               ^
             |                                               |
             v                                               |
   +---------------------------+                             |
   | .github-access-token repo |                             |
   | (global policy)           |                             |
   |  access-token.yaml        |                             |
   +---------------------------+                             |
             |                                               |
             |  defines who can request tokens               |
             v                                               |
   +---------------------------+                             |
   | target repo config        |                             |
   | .github/access-token.yaml |-----------------------------+
   | (local policy)            |
   +---------------------------+
             |
             v
   Tokens issued at workflow runtime
   with correct permissions

Step 2 configure generic policy upon `.github-access-token` repo.

As described above you need to create a repo named .github-access-token, on it I needed to create a file named access-token.yaml.
In my case these are the settings I needed to place upon:


origin: pc-magas/.github-access-token


allowed-repository-permissions:
  actions: write # read or write
  contents: write # read or write
  pull-requests: write # read or write

# Grant owner scoped permissions (owner permission or owner wide repository permissions)
# NOTE: Every statement will always implicitly grant `metadata: read` permission.
statements:
  - subjects:
      - repo:${origin}:ref:refs/heads/dev
      - repo:${origin}:workflow_ref:${origin}/.github/workflows/release.yml@refs/heads/dev
    permissions:
      pull-requests: write

1. origin

The origin field tells the app which .github-access-token repo defines the global policy.
It always follows the format:

OWNER/.github-access-token

OWNER = your GitHub username or organization name
.github-access-token = the special repository that stores the global rules

Examples:

For my personal account (pc-magas), the repo is named pc-magas/.github-access-token
If the owner was an organization named ellakcy, then it would be ellakcy/.github-access-token

This matters because when a workflow requests a token, the app checks:

Which global policy repo (origin) it should look at
Whether that policy allows issuing the token for the requested action

2. `allowed-repository-permissions`

This section sets the maximum permissions a token can have when issued.
Think of it as the "permission budget".
For example:

actions: write → allows running workflows
contents: write → allows pushing/pulling commits
pull-requests: write → allows creating or updating PRs

There is an full template that can be used upon for reference.

3. `statements`

This section defines who is allowed to request a token and what extra permissions they get.
It works like an access control rule:

subjects: → specifies which workflows or branches can ask for tokens
permissions: → specifies what those subjects are allowed to do

Example from above:

statements:
  - subjects:
      - repo:${origin}:ref:refs/heads/dev
      - repo:${origin}:workflow_ref:${origin}/.github/workflows/release.yml@refs/heads/dev
    permissions:
      pull-requests: write

This means:

Only workflows running from the dev branch of the .github-access-token repo can request a token.
Those workflows are granted pull-requests: write permission (so they can open or update PRs).

If you want to allow multiple repositories you need to add multiple sections and what permissions are allowed.

Step 3 Define a local policy on repo you want to perform PR

The local policy lives inside the target repository — the repo where you want to push code or create a pull request.
This policy acts as an explicit opt-in: it tells GitHub, "yes, I allow workflows from these repos/branches to perform actions here."

For my case, this file lives in pc-magas/homebrew-mkdotenv repo upon.github/access-token.yaml file:

origin: pc-magas/homebrew-mkdotenv
statements:
  - subjects:
      - repo:pc-magas/mkdotenv:** # all refs, workflows, environments
    permissions:
      contents: write
      pull-requests: write

The first thing you notice is that this file is a more slimmed-down version of the global policy. Only origin and statements are present here. As before, the origin field simply points to the repository where this local policy file lives. Then, under the statements section, you describe which repositories are allowed to interact with this one and what they are allowed to do.

You can add one or more entries under statements. Each entry can target a different repository or workflow and specify the actions it may perform. The actual actions are defined in the permissions section.

In my case, I allow anything from pc-magas/mkdotenv — whether it’s a branch, a workflow, or an environment — to push code and open pull requests into pc-magas/homebrew-mkdotenv.

Implement Github action

A minimal example of my full worflow is shown below.
Upon myrepo the pipeline has multiple jobs, but the one that matters for creating the pull request is test_homebrew.


test_homebrew:
  runs-on: macos-latest
  permissions:
    contents: write
    id-token: write
  needs:
    - release
    - build_mac
  steps:

    - uses: actions/checkout@v4
      with:
        fetch-depth: 0

    - name: Download homebrew formula for macos
      uses: actions/download-artifact@v4
      with:
        name: mkdotenv-macos-homebrew-formula
        path: ./macos/bin

    - name: Generate GitHub App token
      id: token
      uses: qoomon/actions--access-token@v3
      with:
        repository: pc-magas/homebrew-mkdotenv
        permissions: |
          contents: write
          pull_requests: write

    - name: setup git and clone brew formula
      env:
        GH_PAT: ${{ steps.token.outputs.token }}
      run: |
        git config --global user.name "github-actions"
        git config --global user.email "actions@github.com"

        git clone https://x-access-token:${GH_PAT}@github.com/pc-magas/homebrew-mkdotenv.git
        cd homebrew-mkdotenv

        git checkout -b test-update-formula-${{ github.run_number }}

    - name: setup formula
      run: |
        cd homebrew-mkdotenv
        mkdir -p ./Formula
        cp ../macos/bin/mkdotenv.rb ./Formula/mkdotenv.rb

    - name: Create Pull Request to homebrew repo
      env:
        GH_PAT: ${{ steps.token.outputs.token }}
      run: |
        cd homebrew-mkdotenv

        BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD)
        git add ./Formula/mkdotenv.rb
        git commit -m "Update formula via GitHub Actions"
        git push origin ${BRANCH_NAME}

        VERSION=$(grep -E '^  version ' ./Formula/mkdotenv.rb | sed 's/.*"\(.*\)".*/\1/')

        curl --fail-with-body -vvv -X POST https://api.github.com/repos/pc-magas/homebrew-mkdotenv/pulls \
          -H "Authorization: Bearer $GH_PAT" \
          -H "Accept: application/vnd.github+json" \
          -H "Content-Type: application/json" \
          -H "X-GitHub-Api-Version: 2022-11-28" \
          -d "{\"title\": \"Update formula [VERSION $VERSION]\",\"head\": \"$BRANCH_NAME\",\"base\": \"master\",\"body\": \"Automated update\"}"

The flow follows a simple philosophy:

Clone the target repo
Create a new branch 3.Copy or modify the necessary files 4.Commit and push the changes 5.Open a pull request

The key part is how authentication works. The GitHub App token is generated here:

      - name: Generate GitHub App token
        id: token
        uses: qoomon/actions--access-token@v3
        with:
          repository: pc-magas/homebrew-mkdotenv
          permissions: |
            contents: write
            pull_requests: write

This uses the qoomon/actions--access-token action to issue a temporary token with just the right permissions. The token is then exposed as teps.token.outputs.token and passed into later steps through an environment variable called GH_PAT like this:

 - name: setup git and clone brew formula
        env:
          GH_PAT: ${{ steps.token.outputs.token }}
        run: |
          # These are needed in order to config which does the push and PR
          git config --global user.name "github-actions"
          git config --global user.email "actions@github.com"

          git clone https://x-access-token:${GH_PAT}@github.com/pc-magas/homebrew-mkdotenv.git
          cd homebrew-mkdotenv

          # Create new branch for PR
          git checkout -b test-update-formula-${{ github.run_number }}

When cloning the repo, authentication is set up by injecting that token into the HTTPS URL:

git clone https://x-access-token:${GH_PAT}@github.com/pc-magas/homebrew-mkdotenv.git

Notice the x-access-token:${GH_PAT} part inside the repository URL. This is what enables Git to authenticate in a non-interactive way during the workflow, so the branch can be created and pushed automatically.

The PR itself is done using the Github rest api, we use the very same key we used upon cloning.

For api consumption we need to use curl, the call is performed like this:

          curl --fail-with-body -X POST https://api.github.com/repos/pc-magas/homebrew-mkdotenv/pulls \
            -H "Authorization: Bearer $GH_PAT" \
            -H "Accept: application/vnd.github+json" \
            -H "Content-Type: application/json" \
            -H "X-GitHub-Api-Version: 2022-11-28" \
            -d "{\"title\": \"Update formula [VERSION $VERSION]\",\"head\": \"$BRANCH_NAME\",\"base\": \"master\",\"body\": \"Automated update\"}"

The generated key is provided as bearer token. Also when using curl upon github actions it is nice to aplo place the --fail-with-body argument, that allows if rest api returns an error http status code (such as 4XX or 5XX) the whole step fails, that allows you to have a better view whether PR was created or not.

Dev Experience: `doctrine:schema:update` still outputs sql, despite changes applied upon db

Dimitrios Desyllas — Tue, 02 Sep 2025 16:51:25 +0000

The problem

Today I was deploying an app, team uses diffs instead of migration.

Therefore, I saw what changes upon db needs to be applied via:

$ php bin/console doctrine:schema:update --dump-sql

That outputed me ~93 queries (well lots of changes needed to be applied upon db):

ALTER TABLE xxx1 CHANGE expires\_at expires\_at DATETIME DEFAULT NULL, CHANGE created\_at created\_at DATETIME DEFAULT NULL, CHANGE updated\_at updated\_at DATETIME DEFAULT NULL;

ALTER TABLE xx2 CHANGE name name VARCHAR(255) DEFAULT NULL, CHANGE created\_at created\_at DATETIME DEFAULT NULL, CHANGE updated\_at updated\_at DATETIME DEFAULT NULL, CHANGE unique\_identifier unique\_identifier VARCHAR(255) DEFAULT NULL;

ALTER TABLE xx3 CHANGE description description VARCHAR(255) DEFAULT NULL, CHANGE created\_at created\_at DATETIME DEFAULT NULL, CHANGE updated\_at updated\_at DATETIME DEFAULT NULL, CHANGE deleted\_at deleted\_at DATETIME DEFAULT NULL, CHANGE unique\_identifier unique\_identifier VARCHAR(255) DEFAULT NULL;

.....

Then I tried to apply them via:

$ php bin/console doctrine:schema:update --force

And I re-checked for changes via:

$ php bin/console doctrine:schema:update --dump-sql

And still outputed:

ALTER TABLE xxx1 CHANGE expires\_at expires\_at DATETIME DEFAULT NULL, CHANGE created\_at created\_at DATETIME DEFAULT NULL, CHANGE updated\_at updated\_at DATETIME DEFAULT NULL;

ALTER TABLE xx2 CHANGE name name VARCHAR(255) DEFAULT NULL, CHANGE created\_at created\_at DATETIME DEFAULT NULL, CHANGE updated\_at updated\_at DATETIME DEFAULT NULL, CHANGE unique\_identifier unique\_identifier VARCHAR(255) DEFAULT NULL;

ALTER TABLE xx3 CHANGE description description VARCHAR(255) DEFAULT NULL, CHANGE created\_at created\_at DATETIME DEFAULT NULL, CHANGE updated\_at updated\_at DATETIME DEFAULT NULL, CHANGE deleted\_at deleted\_at DATETIME DEFAULT NULL, CHANGE unique\_identifier unique\_identifier VARCHAR(255) DEFAULT NULL;

As not notice same sql is outputed despite being applied.

The solution

Well, I asked for help from a coleague of mine. He tried to make a migration like this:

php bin/console doctrine:migrations:diff

But that returned the error:

The metadata storage is not up to date, please run the sync-metadata-storage command to fix this issue.

The rationale behind this is because both doctrine:migrations:diff and doctrine:schema:update use same logic for diffs. Migration generation though also exposes any error as well.

The reason why i got both upon migration generation an error and why also schema:update outputes same sql was, a serverVersion option upon .env:

DATABASE_URL=mysql://xxx:yyy@127.0.0.1:3306/testtest?serverVersion=10.4

We use mariadb for db and as you notice above serverVersion contains the mariadb version. The soplution is either get the correct version (incl minor one) from:

mysql --version

And set the serverVersion into mariadb-10.4.1 (yours may differ). The value is comming from the mariadb version shown upon the command above prefixed with mariadb to indicate that it is mariadb instead of mysql.

The option we chose though, was to ditch completely the serverVersion argument upon DATABASE_URL, that fixed the issue as well.

Run background jobs (eg. queue listener) on an environment that does not allow root access.

Dimitrios Desyllas — Thu, 03 Jul 2025 16:33:47 +0000

Recently, in my work, I came across a peculiar problem. I needed to run reliably a queue listener. My go-to solution in this problem is to set up supervisor, but in order to do that requires root/sudo access and I did not have this privilege.

The server does ship with a Linux distro but running apt-get, or any other package manager, does require sudo or su in order to get root access. In my case I was unable to do that.

Well, supervisor is not the only option for utilizing a process manager. There's another option that also comes preinstalled on every linux distro, it is called systemd and many services use that.

Each user can run its own systemd services as non root-user.
First and foremost, you need to create the ~/.config/systemd/user/

mkdir -p ~/.config/systemd/user/

Then we need to place a file upon ~/.config/systemd/user/, for example in my case it was a symfony queueu listener, therefore I run:


nano ~/.config/systemd/user/queue_runner.service

And placed the following contents

[Unit]
Description=Symfony Queue message Listener

StartLimitIntervalSec=20s
StartLimitBurst=5

[Service]
Type=simple

WorkingDirectory=/home/qpassstage/public_html_test
ExecStart=/usr/bin/php -d memory_limit=-1 bin/console messenger:consume async -vv

Restart=always
RestartSec=1
TimeoutSec=300

[Install]
WantedBy=default.target

It is important the filename to end with .service and exist upon ~/.config/systemd/user/ instead of /etc/systemd/system/ where system-wide services live upon.

Also, it is important upon [Install] section of the file to contain:

WantedBy=default.target

Usually upon authoring service file upon Install section contains:

WantedBy=multi.target

The directive default.target allows you to run the service as the default user instead of root user.

Furthermore upon the service file above the command we need to launch as a service is:

 /usr/bin/php -d memory_limit=-1 bin/console messenger:consume async -vv

And is defined upon ExecStart whereas upon WorkingDirectory we define the location where command that will run as a service is located upon.

The section:

Restart=always

Ensures that once command unexpecteddly stops working then systemd would execute it once more.

Launcing Service

Once placed, you need to ensure that systemd has recognized the service:

systemctl --user daemon-reload

Then launch the service. In our case we run:

systemctl --user start queue_runner.service

Then ensure it run upon rebbot via:

systemctl --user enable queue_runner.service

We can use these commands for logs:

systemctl --user status queue_runner.service
journalctl --user -u queue_runner.service -f

In case your user is not upon journal group use file instead by placing these directives upon service file:

[Unit]
Description=Symfony Queue message Listener

StartLimitIntervalSec=20s
StartLimitBurst=5

[Service]
Type=simple

WorkingDirectory=/home/qpassstage/public_html_test
ExecStart=/usr/bin/php -d memory_limit=-1 bin/console messenger:consume async -vv

Restart=always
RestartSec=1
TimeoutSec=300

StandardOutput=append:/home/myapp/public_html/var/log/messenger.log
StandardError=append:/home/myapp/public_html/var/log/messenger.log

[Install]
WantedBy=default.target

And run:

systemctl --user daemon-reload
systemctl --user start queue_runner.service

As you notice, we used the file /home/qpassstage/public_html/var/log/messenger.log to store the output of the command the directive:

StandardOutput

Saves the output of stdout in the file, whilst the:

StandardError

Saves the output of stderr upon the file. In my case the directory /home/myapp/public_html/var/log already existed, therefore I did not make it.

If the folder does not exist, using mkdir -p you can make it:

mkdir -p /home/myapp/public_html/var/log

(Replace /home/myapp/public_html/var/log with your own path, then update service file accordingly.)

Hey you! Deploying the application can you hear me?

Dimitrios Desyllas — Wed, 02 Jul 2025 19:32:13 +0000

Hey you! Setting secrets upon .env file via a CI/CD pipeline, can you hear me?

Recently I am making a small utility tool named mkdotenv. Its goal simple: manipulate values upon .env files in a CI/CD pipeline. It is designed to run inside a pipeline during deployment and modify and set values upon .env files.

It is shipped in #fedora, #ubuntu, #linux, #windows and #mac.

Look here: https://github.com/pc-magas/mkdotenv

Available on Fedora #corpr, Ubuntu/Mint #ppa and #homebrew (for M-Series mac). Also, building from source is easy-peasy-lemon-sqeezy it just needs #go and #make and no other external dependencies.

Please have a strong look as I develop it into a stable version.

How to setup a dev db for symfony development where migration scripts are not used.

Dimitrios Desyllas — Wed, 28 May 2025 20:17:22 +0000

In my work, I develop a symfony application. As usual, migration scripts are abandoned and I have no easy way of setting up a development mysql database in my machine for local development.

But I found an easy solution to setup the db shema.

STEP 1 Import a db dump - initialise database

At the first step, you need to obtain a dump of a development db and import it using mysql. This needs to run every time you create a fresh db instance:

mysql -h 127.0.0.1 -u dbusr -pXXXX somedb < dump.sql

Each time you drop and recreate the db, import the dump it is a good idea to keep it upon your hard disk.

STEP 2 Update schema

Then I use symfony's shema:update and I post-process it (it can generate some unwanted sql):

php bin/console doctrine:schema:update --dump-sql | \
awk '/^ALTER TABLE/ {
    gsub(/,$/, "", $0);
    table=$3;
    sub(/^ALTER TABLE [^ ]+ /, "", $0);
    n=split($0, parts, /, */);
    for (i=1; i<=n; i++) {
        print "ALTER TABLE " table " " parts[i] ";"
    }
    next
}
{ print }
' | \
tee /dev/tty | mysql -h 127.0.0.1 -u dbusr -pXXXX somedb

Let me explain this monstrocity I typed above a bit:

1 Generate schema update sql

php bin/console doctrine:schema:update --dump-sql

With this command I get the SQL from doctrine:schema:update using the parameter --dump-sql

2 Postprocess sql using awk

awk '/^ALTER TABLE/ {
    gsub(/,$/, "", $0);
    table=$3;
    sub(/^ALTER TABLE [^ ]+ /, "", $0);
    n=split($0, parts, /, */);
    for (i=1; i<=n; i++) {
        print "ALTER TABLE " table " " parts[i] ";"
    }
    next
}

Using awk I split any ALTER TABLE sql statement into smaller ones. I use awk because if an ALTER TABLE statement alters multiple colums it may fail.

I wanted each ALTER TABLE statement to add, alter or drop only one column at a time, increasing changes of the updates to successfully run upon db.

That allows me to fix any issues at my own time.

3 Print upon console

tee /dev/tty

With this, I wanted to show what sql statements run upon db whilst I also pass it upon mysql command:

4 run sql statements

mysql --force -h 127.0.0.1 -u dbusr -pXXXX somedb

Finally, using mysql I run the statements that are generated upon db. I use --force option because if ommited and an sql statement fails other will not run upon db.

What I wanted was to run any sql statement that updated the db schema.

Caveats

This method is subpar to the use of db migration scripts. But many cases where for various reasons db migrations are not maintained properly (lack of time or knowledge) this is the next best thing.

If upon your team db migrations used properly this method should be avoided and use the migration scripts to setup the db.

Also this method forces any sql statement to run upon db without some sort of controll or test. Some of them can be dangerous do irreversible damage to db schema. Furthermor a db setup or migrations also need need data migration as well that this method does not provide.

This approach is recommended for a local db setup during development and should be avoided for app deployment.

The good things about this method

This method though offers fixed steps to setup and update a development database at any given moment. Personally, I made 2 bash scripts:

One that nukes and creates a fresh db from a db dump (as mentioned upon step 1):

#!/usr/bin/env bash

mysql -h 127.0.0.1 -u dbusr -pXXXX -e "DROP DATABASE app_db"
mysql -h 127.0.0.1 -u dbusr -pXXXX somedb -e "CREATE DATABASE app_db"

# Init
mysql -h 127.0.0.1 -u dbusr -pXXXX somedb < dump.sql

And one that updates the schema (as mentioned upon step 2)

#!/usr/bin/env bash

php bin/console doctrine:schema:update --dump-sql | \
awk '/^ALTER TABLE/ {
    gsub(/,$/, "", $0);
    table=$3;
    sub(/^ALTER TABLE [^ ]+ /, "", $0);
    n=split($0, parts, /, */);
    for (i=1; i<=n; i++) {
        print "ALTER TABLE " table " " parts[i] ";"
    }
    next
}
{ print }
' | \
tee /dev/tty | mysql -h 127.0.0.1 -u dbusr -pXXXX somedb

These can be adjusted for example if php app runs through a docker container named php:

#!/usr/bin/env bash

docker exec -u www-data php php bin/console doctrine:schema:update --dump-sql  | \
awk '/^ALTER TABLE/ {
    gsub(/,$/, "", $0);
    table=$3;
    sub(/^ALTER TABLE [^ ]+ /, "", $0);
    n=split($0, parts, /, */);
    for (i=1; i<=n; i++) {
        print "ALTER TABLE " table " " parts[i] ";"
    }
    next
}
{ print }
' | \
tee /dev/tty | mysql -h 127.0.0.1 -u dbusr -pXXXX somedb

I hope this to be found usefull.

Mkdotenv: the tool that makes .env manipulation a breeze

Dimitrios Desyllas — Mon, 07 Apr 2025 19:55:33 +0000

Hello hello hello,
Recently, I got my hands dirty with go and made a simple tool for manipulating .env files:

https://github.com/pc-magas/mkdotenv

Currently, I release for linux (x86_64 architectures) with debian and rpm packages. I also attempted to release for alpine but somehow got stuck in aports.

Also, it is available through ppa: https://launchpad.net/~pcmagas/+archive/ubuntu/mkdotenv and includes a full manpage as well:

man mkdotenv

Feel free to download and place any issue in: https://github.com/pc-magas/mkdotenv/issues

I made this because I thought a tool that is able to run in a CI/CD pipeline and manipulates .env file before releasing your app into production (or staging) maybe a good idea.

External Versioning in GCC: Defining Project Versions Without Modifying Source Code

Dimitrios Desyllas — Sat, 08 Mar 2025 15:45:35 +0000

I was experimenting with gcc linker and how I could define the version of my project externally. The idea is to have a version bump procedure, but without needing to modify source code for just a version.

So assuming we have this file named test.c:

#include <stdio.h>
#ifndef VERSION
#define VERSION "default"
#endif

int main(){
    printf(VERSION);
}

This is a piece of code that needs to output its version Instead of relying in a constant, we define the version with a placeholder.

The #define is a way to define macros, pieces of code that the preprocessor of the compiler will take and replace the values inside out actual code.

In our case, the preprocessor will replace the constant version with string "default". So once compiled, the piece of software above will just print default if compiled like this:

gcc test.c
chmod +x ./a.out
./a.out
default

But as no noticed we did not just place a simple #define but instead we used #ifndef ... #endif. With that we tell the preprocessor to define the VERSION if not defined.

But is there a way to define it externally? YES babe YES we use the -D argument to define the desired version:

gcc -DVERSION="\"0.9.0\"" test.c
chmod +x ./a.out
./a.out

Will output:

0.9.0

With the gcc's -D parameter we defined the constant VERSION externally resulting for the VERSION to be defined as 0.9.0 and not as default.

Therefore, we can use a file in which contains the version. Usually I name it VERSION. In our case it will contain:

0.9.0

Then I use a Makefile to build it:

VERSION := $(shell cat VERSION)
CC := go

.PHONY: all compile

# Default target
all: compile

# Compile Go binary
compile:
    gcc -DVERSION="\"$(VERSION)\"" test.c

So in order to compile I just run:

make

With this, I can version bump my project upon release. I just need to place the necessary version without needing to modify code, but instead I can set it upon compile time.

Do not use from with getRepository when creating query builder

Dimitrios Desyllas — Tue, 04 Mar 2025 17:37:08 +0000

In my symfony project, I was using the query builder in order to query a table:

namespace App\Infrastructure\Services;

use Doctrine\ORM\EntityManagerInterface;

use App\Entity\MyModel

class FetchResultFromDb 
{

    public function __construct(private EntityManagerInterface $entityManager)
    {
    }


    public function getEarliestResult(int $rowNum)
    {

        $queryBuilder = $this->entityManager->getRepository(MyModel::class)->createQueryBuilder('m');

        return $queryBuilder
            ->from(MyModel::class, 'm')
            ->select('m.id')
            ->orderBy('m.sentTimestamp', 'ASC')
            ->setMaxResults($rowNum)
            ->getQuery()
            ->getResult();

    }  

}

But I noticed that calling the getEarliestResult on a row containing ~10000 rows took too long:

namespace App\Command;


use Symfony\Component\Console\Attribute\AsCommand;
use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Input\InputArgument;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Input\InputOption;
use Symfony\Component\Console\Output\OutputInterface;
use Symfony\Component\Console\Style\SymfonyStyle;

#[AsCommand(
    name: 'test:query',
    description: 'Add a short description for your command',
)]
class TestQueryCommand extends Command
{
    public function __construct(private readonly FetchResultFromDb $service)
    {
        parent::__construct();
    }

    protected function execute(InputInterface $input, OutputInterface $output): int
    {
        $results = $this->service->getEarliestResult(5000);

        // Rest of code gows here ommited for simplicity
    }
}

In my case was ~75 second.

In order to see the cause of this delay the first stem was to refactor my method and dump the generated SQL:

namespace App\Infrastructure\Services;

use Doctrine\ORM\EntityManagerInterface;

use App\Entity\MyModel

class FetchResultFromDb 
{

    public function __construct(private EntityManagerInterface $entityManager)
    {
    }


    public function getEarliestResult(int $rowNum)
    {

        $queryBuilder = $this->entityManager->getRepository(MyModel::class)->createQueryBuilder('m');

        $q=$queryBuilder
            ->from(MyModel::class, 'm')
            ->select('m.id')
            ->orderBy('m.sentTimestamp', 'ASC')
            ->setMaxResults($rowNum)
            ->getQuery();

       dump($q->getSql());
       return $q->getResult();
    }  

}

But the dump resulted retrieving this sql:

SELECT m0_.id AS id_0 FROM my_model m1_, my_model m0_ ORDER BY m0_.sent_timestamp ASC LIMIT 5000;

As you can see, the query does a cartetian product of all entries in database. That means that query iterates 5000X5000=25000000 results for just fetching only the 5000.

That is wasteful of resources. In my case, I just wanted to do a simpler query:

SELECT id from my_model order by sent_timestamp LIMIT 5000

SOLUTION

I managed to solve it this issue using 2 approaches:

Approach 1 Do not use `getRepository` when creating a query builder:

namespace App\Infrastructure\Services;

use Doctrine\ORM\EntityManagerInterface;

use App\Entity\MyModel

class FetchResultFromDb 
{

    public function __construct(private EntityManagerInterface $entityManager)
    {
    }


    public function getEarliestResult(int $rowNum)
    {

        $queryBuilder = $this->entityManager->createQueryBuilder('m');

        return $queryBuilder
            ->from(MyModel::class, 'm')
            ->select('m.id')
            ->orderBy('m.sentTimestamp', 'ASC')
            ->setMaxResults($rowNum)
            ->getQuery()
            ->getResult();

    }  

}

As you can see, instead of using $this->entityManager->getRepository(MyModel::class)->createQueryBuilder('m'); I used $this->entityManager->createQueryBuilder('m');

In other words, I removed the call of the method getRepository

Approach 2 Do not use `from` in the query Builder:

namespace App\Infrastructure\Services;

use Doctrine\ORM\EntityManagerInterface;

use App\Entity\MyModel

class FetchResultFromDb 
{

    public function __construct(private EntityManagerInterface $entityManager)
    {
    }


    public function getEarliestResult(int $rowNum)
    {

        $queryBuilder = $this->entityManager->getRepository(MyModel::class)->createQueryBuilder('m');

        $q=$queryBuilder
            ->select('m.id')
            ->orderBy('m.sentTimestamp', 'ASC')
            ->setMaxResults($rowNum)
            ->getQuery();

       return $q->getResult();
    }  

}

Calling getRepository(MyModel::class) and then createQueryBuilder('m') has a result for the query builder to append on its own the necessary from section in the final sql that qill be executed upon db.

Therefore, placing from does not offer any beneft whatoever.

Conclution

To sum up when creating a query builder do it like this:

$this->entityManager->createQueryBuilder('m');

If you get the repository first avoid using from because it results a cartetian product.

How I can join with count subquery upon doctrine?

Dimitrios Desyllas — Tue, 04 Mar 2025 17:11:05 +0000

Hello can you help me with this?

https://stackoverflow.com/questions/79484363/how-i-can-join-using-counts-using-doctrine

What I try to do is run the following query:

select
    user.*,
    business_count.count
from
    user
join (
    select
        count(*) as count,
        user_id
    from
        business
    group by
        user_id) as business_count on business_count.user_id = user.id;

Using the doctrine's query builder. But for not it does not allow me:

  [Semantical Error] line 0, col 48 near 'JOIN (SELECT': Error: Subquery is not supported here

Therefore, I am exploring any solutikn to this.