Let python-dotenv be the only reader of .env

[Isma-L154]

Closes #19

The problem

.env was parsed by two things with different rules:

• systemd, via EnvironmentFile= in the loopify-bot unit
• python-dotenv, via load_dotenv() in config.py

They disagree about quoting, inline comments, and values containing #, spaces or =.

The live host logs the disagreement on every single start:

loopify-bot.service: Ignoring invalid environment assignment '<a URL>': /home/ubuntu/LoopifyBot/.env

Harmless in that instance — the line is not a required variable — but it is the same file diverging between the two readers, in production, right now.

Why it matters

A token containing a # gets truncated by one parser and not the other. The bot then fails to authenticate, and the symptom looks like a bad credential rather than a parsing problem — which is a genuinely unpleasant thing to chase, especially since you cannot paste the token anywhere to compare.

The fix

python-dotenv owns the file. EnvironmentFile= is dropped from the unit, with a comment saying why so nobody adds it back as an obvious-looking improvement.

The path is also anchored to the project root rather than left to search upward from the working directory:

PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
load_dotenv(os.path.join(PROJECT_ROOT, ".env"))

Otherwise the bot picks up a different file depending on where it was started from — systemd sets WorkingDirectory, but a shell invocation from anywhere else does not.

.env.example now states the rules, including the one that actually bites people: a trailing comment after a value is part of the value.

Nothing is lost by removing it

load_dotenv() writes into os.environ, so subprocesses (yt-dlp) inherit the same variables they did before. The unit's own Environment= lines for XDG_CACHE_HOME and DENO_DIR are unaffected, and load_dotenv does not override already-set variables, so they still win.

Verification

232 passed. Two new tests, both non-vacuous:

• .env resolution is anchored to the project root.
• deploy/setup.sh declares no active EnvironmentFile line. The check filters out commented lines, so the explanatory comment does not make it pass trivially — re-adding the directive fails the suite.

To confirm after deploy, the warning should be gone from a fresh start:

sudo journalctl -u loopify-bot --since "-2 min" | grep -i "invalid environment"