webqueue2-api repository plan

[benne238]

To make development easier, the backend will (eventually) be completely moved to a new repository. This presents a number of configuration changes including:

• Development tools, specifically creating new scripts to replace npm
• Versioning and being able to install the backend from github in production
• How to implement "nested" git directories in the frontend (potentially, however this might be more of a front end issue)

The biggest of these issues is being able to allow the backend to be easily installed for production via pip most likely.

Next steps

• Determining how github python packages work and being able to answer these specific questions:

  • what version of a package is installed by default?
  • how does installing via pip from a github repo affect the version number when running pip freeze?
  • is it possible to specify a version of a python package to install when installing from github, and is it possible to do this without using tags as mentioned in this comment?
  • determine a work flow for the frontend when installing the backend in regard to different versions of the backend being accessible, so communicating what changes occur from version to version is important

• Creating (a) custom script(s) that replace npm to:

  • Create, reset, and delete the virtual environment
  • Activate and deactivate the virtual environment (possibly)
  • Run the api locally to test changes

[campb303]

Some comments:

How to implement "nested" git directories in the frontend (potentially, however this might be more of a front end issue)

Look into git sub-modules.

is it possible to specify a version of a python package to install when installing from github, and is it possible to do this without using tags as mentioned in this comment?

Why not use tags? We'd talked about the want for version numbers to match release versions but this can be done just by using the same version number in the Python package and in the git tag.

determine a work flow for the frontend when installing the backend in regard to different versions of the backend being accessible, so communicating what changes occur from version to version is important

Versioning can and should be done via a requirements file for pip. Communicating changes can be done via release notes.

Activate and deactivate the virtual environment (possibly)

This shouldn't be necessary as VSCode understands virtual environments and auto activates during debugging and it is a single source path/to/venv/bin/activate command to activate manually.

[campb303]

Current work for this is being tracked in #159

[campb303]

The API has now been migrated to a standalone repository and can be installed via pip or a requirements file. Closing.