Did we fix all the methods to use Fedora 28 and Python 3 yet? The current methods are kind of rotted from how they should be working...

I think we should default to python3 here

This needs to be fix, it's a valid test that we really want to keep.

@alexgleason With this your fix I'm finally able to use the local instance on docker compose, thanks :) I only needed to install mock.

It could be done in a separate PR. There is no option for Python 3. I am simply fixing the existing environment, not adding to it yet.

Maybe this relies on using Python 3. It wouldn't work in Python 2. What do you suggest?

Switching the dev environment to Python 3 is also a big change. Is there any way you can help me fix the test to work in Python 2 for now and then handle Python 3 in a separate PR?

Issues with tests aside, I need to push another commit to fix mock not being installed in the container by default and apparently there's still a small bug when running dev-data.py

Okay, I got mock installed in the container now.

I learned the hard way that when testing docker-compose, you must delete everything and start over to ensure it's a clean environment.

# Delete EVERYTHING
docker-compose -f dev/docker-compose.yml rm
docker volume prune
sudo git clean -fdx
# Now start over
mkdir -p lcl/{repos,remotes,attachments,releases}
docker-compose -f dev/docker-compose.yml build
docker-compose -f dev/docker-compose.yml up

I'm still running into another problem. I hardcoded the ID's of database objects, because later in the script it accesses them by ID. Running the script more than once makes the second part of the script break because of autoindex. Sadly, now we have the reverse problem. Creating a new data object with autoindex will complain that an object with id=1 already exists because apparently inserting a row where the pkey is explicit prevents autoindex from incrementing. So parts of the script need to be fixed to stop relying on IDs.

Okay, I am leaving the tests alone now. Instead, I copied the function I needed directly into dev-data.py for now. Perhaps it's heavy-handed, but at least it works, which is an improvement.

I think this can be merged now and Python 3 can be handled in a separate PR since Python 3 support never existed for docker-compose (or Vagrant) in the first place.

It says "this pull request must be rebased before merging" but...

I tried

git fetch origin
git merge origin/master
git push alex onboarding

and it shows 52 file changes and diffs for the entire merge commit in the Pagure UI. Is that a bug in Pagure and I should go ahead and push that version back? (I force pushed to how it was before).

That's because you use merge, what you want is rebase.
An handy way to get it is git pull --rebase origin master on your working branch. You will then need to force-push since you re-wrote history but this way pagure's history remains linear :)

I see. I almost used cherry-pick but this is way better, thanks! Updated my branch.

I also added TEMPLATES_AUTO_RELOAD = True to the Compose environment. Without it, Jinja will cache templates and won't reload them without restarting the whole dev server.

I also added TEMPLATES_AUTO_RELOAD = True to the Compose environment. Without it, Jinja will cache templates and won't reload them without restarting the whole dev server.

Good idea, it's also useful to debug theming sometime