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
Previously it was possible to have vscode (or another ide) set up so all dependencies referenced in addons-server could be resolved. This meant you could seamlessly inspect the python code for a dependency in the same way you could navigate to a file within addons-server's codebase. Most often this would be a django .py but with all the dependencies there it could be any package. This all "broke" when we stopped installing dependencies in a sub-directory in the addons-server directory (for startup efficiency)
Acceptance Criteria
The content you are editing has changed. Please copy your edits and refresh the page.
Ugly workaround we discussed during Office Hours: install deps in a dummy virtualenv and point vscode to that.
Alternatively we could find ways to expose the docker container deps to the host, maybe through a volume like we used to, or maybe though some vscode extension that would deal with docker.
@KevinMind if #15066 will fix this (in a more comprehensive way) is it worth putting any effort into getting dependency resolution to work with the current setup?
Description
Previously it was possible to have vscode (or another ide) set up so all dependencies referenced in addons-server could be resolved. This meant you could seamlessly inspect the python code for a dependency in the same way you could navigate to a file within addons-server's codebase. Most often this would be a django .py but with all the dependencies there it could be any package. This all "broke" when we stopped installing dependencies in a sub-directory in the addons-server directory (for startup efficiency)
Acceptance Criteria
Milestones/checkpoints
Checks
┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: