Currently, all terra apps use terra's Pipfile for the terra environment.
Unfortunately the move of pipenv to drop markered packages that are not being used by the currently locking python is causing a ripple affect, that is starting to be noticed as we upgrade some of our pythons.
We already knew we could no longer rely on pipenv for cross platform package tracking.
This is also limiting our ability to support different versions of python.
To combat this problem and handle other situations, a method of maintaining a terra Pipfile.lock in the project rather than in the external terra is proposed:
Start off by copying the external/terra/Pipfile to terra_env/Pipfile.
The Terra_Pipenv function can be part of this process, checking if the file is different every time you run Terra_Pipenv, and either tell the user it's out of date, or start an update process
This means each terra app can lock to a specific version of python, rather than leaving it in a lose range of support, like terra is.
Allows a specific project to use specific versions of packages it may require.
If the CLI/workflow/service definition ever needed a third party package, this can be supported (where as now, it cannot without using PYTHONPATH.)
Currently, all terra apps use terra's Pipfile for the terra environment.
Unfortunately the move of pipenv to drop markered packages that are not being used by the currently locking python is causing a ripple affect, that is starting to be noticed as we upgrade some of our pythons.
To combat this problem and handle other situations, a method of maintaining a terra
Pipfile.lockin the project rather than in the external terra is proposed:external/terra/Pipfiletoterra_env/Pipfile.Terra_Pipenvfunction can be part of this process, checking if the file is different every time you run Terra_Pipenv, and either tell the user it's out of date, or start an update process