Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide ability to re-inspect a project interpreter dependencies #2486

Open
sagerb opened this issue Dec 12, 2024 · 0 comments
Open

Provide ability to re-inspect a project interpreter dependencies #2486

sagerb opened this issue Dec 12, 2024 · 0 comments

Comments

@sagerb
Copy link
Collaborator

sagerb commented Dec 12, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant