You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Much of our configuration is based on an initial inspection of the files surrounding the entrypoint file, captured at the time a deployment is created and is not refreshed as changes are made.
Our assumption within the publisher is that the project is fairly complete, and the user won’t be modifying it much. But the reality is that if they are iterating on it, for example, adding a Python section into their Quarto document, which wasn’t originally there, then we really need the option to detect that requirement and update the configuration and manifest as the updated project is deployed. Right now, we’d continue to deploy it without the Python dependency, and the Quarto doc would never run successfully on Connect.
For example, if the content type does not specifically indicate that R is required, we will not indicate a dependency on it if there is no renv.lock file. It seems reasonable that a re-inspect might be useful as the user works on the project, adding functionality. In our current implementation, a user must create a new deployment or manually update the existing configuration. (They could also create a new deployment just to get the config file and then swap the config file to be used with the deployment... but that is pretty complex for a normal workflow.)
I could see us taking a position that we’ll move (or at least re-analyze) the “needsR” and “needsPython” logic, currently done as part of the initial inspection process that creates the config when the user initiates a deployment.
The only way we have to work around this is to suggest that the user create a new deployment, which would perform a new inspection and create a new configuration file. They could then assign the configuration file to the existing deployment or move to a new deployment on the server with the new config/deployment files. The workflow for this common scenario is not great.
The text was updated successfully, but these errors were encountered:
Much of our configuration is based on an initial inspection of the files surrounding the entrypoint file, captured at the time a deployment is created and is not refreshed as changes are made.
Our assumption within the publisher is that the project is fairly complete, and the user won’t be modifying it much. But the reality is that if they are iterating on it, for example, adding a Python section into their Quarto document, which wasn’t originally there, then we really need the option to detect that requirement and update the configuration and manifest as the updated project is deployed. Right now, we’d continue to deploy it without the Python dependency, and the Quarto doc would never run successfully on Connect.
For example, if the content type does not specifically indicate that R is required, we will not indicate a dependency on it if there is no
renv.lock
file. It seems reasonable that a re-inspect might be useful as the user works on the project, adding functionality. In our current implementation, a user must create a new deployment or manually update the existing configuration. (They could also create a new deployment just to get the config file and then swap the config file to be used with the deployment... but that is pretty complex for a normal workflow.)I could see us taking a position that we’ll move (or at least re-analyze) the “needsR” and “needsPython” logic, currently done as part of the initial inspection process that creates the config when the user initiates a deployment.
The only way we have to work around this is to suggest that the user create a new deployment, which would perform a new inspection and create a new configuration file. They could then assign the configuration file to the existing deployment or move to a new deployment on the server with the new config/deployment files. The workflow for this common scenario is not great.
The text was updated successfully, but these errors were encountered: