There are a number of circumstances where users of this application may want to run dev and prod instances on the same logical system. This may make sense, for example, in cloud environments where you want to reduce costs and architectural complexity; or on physical mainframes where it does not make sense to use two different physical servers for a dev and a prod instance.
Ultimately, libreforms-fastapi makes it a straightforward exercise to run a dev and a prod instance on the same system because the systemd daemons will use separate naming conventions for each environment, that is, at least when users deploy and daemonize the application using the CLI that ships with the application. For more information on how to do this, you can review the README.
There are two important reasons why it would make sense to run a dev & a prod instance. First, it makes sense to test out different system configurations and end user interactions with the UI on a dev system before merging these into production. I consider these to be the experiential use cases of a dev-prod segmentation. When new users start using the application, they can use the dev instance to learn how to use the system and not have to worry about breaking it. You can also play around with different form configurations and let users test it in the dev environment before merging these onto the mainline. And finally, you can test different application configurations as well to make sure that they work from the perspective of the end user before merging these into the prod environment too. This is experiential in the sense that they are all ultimately based on the user reaction to system configurations. Since this is all managed through configs, and this application separates dev and prod configs by default, you could theoretically satisfy the experiential requirements of dev-prod segmentation by running both instances out of the same working directory, and using the same virtual environment
The second use case for dev-prod segmentation is less related to the experience, and more related to version-management: maybe you want to test an update or a major version upgrade against a dev instance before merging it into the prod instance. To satisfy the versioning component of dev-prod segmentation, you will need two separate virtual environments, and possible two separate working directories, for your dev and prod instance. If you are installing the application using pip, then you can theoretically use the same working directory and just use two separate virtual environments. However, this is still not recommended because the CLI makes certain assumptions around the name of the virtual environment, and you would need to manually edit the systemd unit file to point it to a different virtual environment (or, we can modify the CLI to allow you to pass path overrides for the virtual environment). But, if you are using git to manage versions of the application, then you will certainly need two separate working directories because the application logic will be stored directly within that working directory. So, there is no way to properly segment a dev and prod instance when you've installed via git into the same working directory. The easiest way around this is to just install into two different working directories, eg. /opt/dev_libreforms and /opt/prod_libreforms.
There are a number of circumstances where users of this application may want to run dev and prod instances on the same logical system. This may make sense, for example, in cloud environments where you want to reduce costs and architectural complexity; or on physical mainframes where it does not make sense to use two different physical servers for a dev and a prod instance.
Ultimately, libreforms-fastapi makes it a straightforward exercise to run a dev and a prod instance on the same system because the systemd daemons will use separate naming conventions for each environment, that is, at least when users deploy and daemonize the application using the CLI that ships with the application. For more information on how to do this, you can review the README.
There are two important reasons why it would make sense to run a dev & a prod instance. First, it makes sense to test out different system configurations and end user interactions with the UI on a dev system before merging these into production. I consider these to be the experiential use cases of a dev-prod segmentation. When new users start using the application, they can use the dev instance to learn how to use the system and not have to worry about breaking it. You can also play around with different form configurations and let users test it in the dev environment before merging these onto the mainline. And finally, you can test different application configurations as well to make sure that they work from the perspective of the end user before merging these into the prod environment too. This is experiential in the sense that they are all ultimately based on the user reaction to system configurations. Since this is all managed through configs, and this application separates dev and prod configs by default, you could theoretically satisfy the experiential requirements of dev-prod segmentation by running both instances out of the same working directory, and using the same virtual environment
The second use case for dev-prod segmentation is less related to the experience, and more related to version-management: maybe you want to test an update or a major version upgrade against a dev instance before merging it into the prod instance. To satisfy the versioning component of dev-prod segmentation, you will need two separate virtual environments, and possible two separate working directories, for your dev and prod instance. If you are installing the application using pip, then you can theoretically use the same working directory and just use two separate virtual environments. However, this is still not recommended because the CLI makes certain assumptions around the name of the virtual environment, and you would need to manually edit the systemd unit file to point it to a different virtual environment (or, we can modify the CLI to allow you to pass path overrides for the virtual environment). But, if you are using git to manage versions of the application, then you will certainly need two separate working directories because the application logic will be stored directly within that working directory. So, there is no way to properly segment a dev and prod instance when you've installed via git into the same working directory. The easiest way around this is to just install into two different working directories, eg.
/opt/dev_libreformsand/opt/prod_libreforms.