The `docker compose build` command fails on fresh projects, because there is no Pipfile.lock

[whusterj]

To reproduce:

1. Run the cookiecutter command as usual
2. cd into your new project
3. Run make build or docker compose build

The build will fail because Pipfile.lock does not exist.

To get Pipfile.lock to exist, you would have to run pipenv install locally, which means you have to make sure Python and pipenv are set up properly on your local. IMO this defeats the purpose of using docker to contain these dependencies.

Options to discuss:

1. Add a Pipfile.lock - though, I think this was struck down
2. Adjust the Dockerfile to not require Pipfile.lock

[whusterj]

Talked to @oudeismetis about this - there are instructions in the project README that I missed that say to run pipenv lock, so you do NOT need to do a full pipenv install.

For a fresh developer, I believe this means setup will still depend on having the correct Python version and pipenv installed locally outside of Docker, and those steps aren't currently documented.

[paribaker]

Circling back to this maybe it is worth having a lock file pre-generated for us. Testing things out on an M1 chip can be annoying depending on what the working patch of pipenv exists.

[oudeismetis]

The general goal with not having lock files pre-generated is to nudge/encourage/force projects to be using newer versions of libraries when the project starts and to avoid new projects starting far beyond on dependencies and then staying behind until a difficult upgrade is required.

That said, I'm open to discussing. I think there are other ways to accomplish the above.

[whusterj]

My two cents: it seems like a balancing act between providing a known good set of dependencies that should "just work" vs. shooting for newer dependencies that could break unexpectedly during bootstrapping. When this breaks, it is a total showstopper and requires some special knowledge to fix.

And then, as Pari pointed out, even the known good deps can fail if the hardware/OS environment changes.

Ideas:

Perhaps we can use Dependabot or something like that to keep dependencies up to date so we can provide a working (tested) lock file?

And, more ambitiously: I have some M1 Mac Minis at the office we could put on the server rack and configure to run tests on M1 hardware and new Mac OS versions.