Add .devcontainer capabilities

[e-lo]

What existing problem does the pull request solve and why should we include it?

As a developer, I'd like to work in a consistent development environment.

This pull request works towards this capability by adding a .devcontainer and .vscode settings.

.devcontainer

• .devcontainer setup which defines a development container for VS Code

This can be leveraged when working in https://vscode.dev/ web-based IDE environment. However, creating the capability to to development completely requires organizations to sign up for GitHub Codespaces in their enterprise subscription.

Another potentially interesting option for MTC would be to configuring a local-server on a machine that has an Emme license.

.vscode

settings.json

As of now there are not a lot of project-specific settings that I could think of, but included a small handful.

extensions

Added a handful of useful ones as "recommended".

@lmz I leave it to you to decide if/when/how to integrate this PR - my guess is that it is most useful as you have staff working on this.

Applicable Issues

Addresses #20

[DavidOry]

I was just going to do this for the Acceptance Criteria work. I'll review.

[DavidOry]

Why is the .devcontainer using a separate Dockerfile than the Dockerfile in the root directory? If we all agree that we want to do development in vscode with the development container, can we get rid of the Dockerfile in the root directory? Getting Jupyter notebooks to work in vscode is much simpler with the development containers.

[DavidOry]

I cannot run the tests and it appears the dev container does not install tm2py. Perhaps a brief adding a brief README would be helpful to guide the user in making sure the environment is set up correctly. Is running the tests the best way?

[DavidOry]

Recommending removing copilot given it's a subscription service.

[DavidOry]

It's also not clear to me if environment.yml is still being used. It appears the development container is not using miniconda. Why not? Is environment.yml being used in the development container at all?

[DavidOry]

It would also be nice to update GitHub Actions to use the same environment. With this change in place we'll be developing in one environment, testing in another, and asking users to run in it in a third. We're kind of stuck with two, given the Emme dependency, but it would be good to limit the Linux environments to one.

[DavidOry]

What are your thoughts on being more prescriptive about Python (and conda, if we switch to a conda-based container) package versions in the requirements.txt document? I would think a key benefit of containerization is stability over time, but it's hard to accomplish that when you are loose with the Python package versions we want to use.