Stop creating new toy assets when restarting the docker-compose stack

[Copilot]

Each docker compose up re-ran flexmeasures add toy-account, which skipped account/user creation (those check for existence) but always recreated all toy assets, resulting in N copies after N restarts.

Changes

• docker-compose.yml — Server startup command now gates toy account creation on a state file: if flexmeasures-instance/.toy-account-created does not yet exist, the toy account is created and the file is touched; subsequent restarts skip creation with an informative message:

if [ ! -f /usr/var/flexmeasures-instance/.toy-account-created ]; then
  flexmeasures add toy-account --name 'Docker Toy Account'
  touch /usr/var/flexmeasures-instance/.toy-account-created
else
  echo "Not creating toy account (already happened once). You can run 'flexmeasures add toy-account' any time."
fi

• .gitignore — Added /flexmeasures-instance so the state file (and any user-local config such as flexmeasures.cfg) is never accidentally committed.
• documentation/dev/docker-compose.rst — Updated to reflect the first-run-only behaviour.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Stop creating new toy assets when restarting the docker-compose stack</issue_title>
<issue_description>### Current situation

1. User runs docker compose up using the docker-compose.yml: toy account, toy user and toy assets created. Assets:
   • NL transmission zone
   • toy-building
   • toy-battery
   • toy-solar
2. User reruns docker compose up: toy account and toy user already exist (not recreated), but some of the toy assets are recreated. Assets:
   • NL transmission zone
   • toy-building (x2)
   • toy-battery (x2)
   • toy-solar (x2)
3. Et cetera. Assets after N down -> up:
   • NL transmission zone
   • toy-building (x N)
   • toy-battery (x N)
   • toy-solar (x N)

Ideas

1. Adjust cli.data_add.add_toy_account to prevent new toy assets being created if they exist already.
2. Adjust docker-compose.yml to not rerun flexmeasures add toy-account --name 'Docker Toy Account' when that account already exists.

   if ! flexmeasures list accounts | grep -q "Docker Toy Account"; then
       flexmeasures add toy-account --name 'Docker Toy Account'
   fi
   

3. Adjust docker-compose.yml to not rerun flexmeasures add toy-account --name 'Docker Toy Account' after the first time docker compose up ran.

   if [ ! -f /app/instance/.toy_account_created ]; then
       flexmeasures add toy-account --name 'Docker Toy Account'
       touch /app/instance/.toy_account_created
   fi
   

Considerations

From a user perspective, I like the third option best. Why? Because I imagine that as a first-time user it's nice that you get a toy site to play around with, but once you set up your own site you will probably delete the toy site/account and it would feel really weird when it reappears the next time you run docker compose up. Even better might be to do the opposite, by having the marker file (named .create-toy-account) in the repo, and removing it the first time docker compose up runs. That way it's slightly nicer in the sense that a) the marker file does not need to live indefinitely on the user's device, and b) having the file explicitly in our repo better signals this design pattern, where temporary marker files are used for first-time use, and this can even be clearly documented inside the file itself.
</issue_description>

Comments on the Issue (you are @copilot in this section)

@nhoening Pretty good analysis.

• Maybe more explicit name: .create-toy-account-on-first-run.
• Would it apply only to running per docker compose or in general?
• We can also consider adding a line to the output which says "Not creating toy account (already happened once). You can run flexmeasures add toy-account any time."</comment_new>
  <comment_new>@Flix6x
  Good suggestions. I had in mind only the docker compose usage for this feature.</comment_new>
  <comment_new>@nhoening
  It could be for using Docker in general</comment_new>
  <comment_new>@Flix6x
  I don't understand, please elaborate. The instructions that add the toy account are in the docker-compose.yml, which is why that is my point of focus.</comment_new>
  <comment_new>@nhoening

I don't understand, please elaborate. The instructions that add the toy account are in the docker-compose.yml, which is why that is my point of focus.

Ah you are correct, so let's limit it to docker compose, indeed.

So I would rename the state file and add something to the output, as suggested.</comment_new>
<comment_new>@Flix6x
I guess a logical place for the marker/state file to live would be in the flexmeasures-instance folder. The repo itself does not have that yet. Is that where we should put it? Or instance? Or otherwise?</comment_new>
<comment_new>@nhoening
Flask has a definition of an instance directory, in the code we find it via Flask("flexmeasures").instance_path (found it in config_utils.py).

Maybe this helps?

import os
from flask import Flask

os.path.join(
    Flask("flexmeasures").instance_path, ".create-toy-account-on-first-run"
)
```</body></comment_new>
<comment_new><author>@Flix6x</author><body>
I guess it should be the directory on the host machine that ends up being mapped to that Flask instance folder inside the container. So that would be the flexmeasures-instance folder on the host container, according to our own `docker-compose.yml`.</body></comment_new>
</comments>

• Fixes Stop creating new toy assets when restarting the docker-compose stack #2013

---

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.

[read-the-docs-community]

Documentation build overview

📚 flexmeasures | 🛠️ Build #31775225 | 📁 Comparing bae24ca against latest (c6bb60f)

🔍 Preview build

Show files changed (3 files in total): 📝 3 modified | ➕ 0 added | ➖ 0 deleted

File	Status
changelog.html	📝 modified
api/v3_0.html	📝 modified
dev/docker-compose.html	📝 modified

[Flix6x]

I reviewed and tested this and it works as advertised.

@nhoening I'd like to get your opinion on these two issues:

• I did have a local flexmeasures-instance directory with a requirements.txt whose contents I needed to move into the new requirements.txt that would now become part of the repo. If you want, we could also leave this file out. What do you think?
• After running docker compose up, the state file is removed and it will keep showing up in the git diff. My IDE did let me move the change into a separate change list, so I'm not bothered by it that much. The only way I see around that would be to move the state information into Postgres instead. What do you think?

[nhoening]

I don't understand the first issue. Be aware that we are moving away from requirements.txt files, apart from using them in plugins probably.

The second issue: I guess we should flip the file to mark when we have done it, and not have it in git (in fact, add it to .gitignore)

[Flix6x]

Good suggestion.

@copilot flip the marker logic as suggested by @nhoening, and remove the new requirements.txt. I guess this means that there is then no longer a need for the flexmeasures-instance folder and its internal .gitignore to be part of the repo, because you can just reference the flexmeasures-instance folder in the main .gitignore instead.

You must not change the PR title and you must append to the PR description of this PR (#2018). Do not replace its current contents.

[Copilot]

Good suggestion.

@copilot flip the marker logic as suggested by @nhoening, and remove the new requirements.txt. I guess this means that there is then no longer a need for the `f...

Done in bae24ca. The marker logic is now flipped: the docker-compose.yml checks for absence of /usr/var/flexmeasures-instance/.toy-account-created and creates it after the first run (no more file deletion). The flexmeasures-instance/ directory and all its files (including requirements.txt) have been removed from the repo, and /flexmeasures-instance is now in the main .gitignore so the state file is never tracked.