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

Address duplication of paths between rdctl and typescript paths module #3652

Closed
adamkpickering opened this issue Dec 16, 2022 · 1 comment · Fixed by #4160
Closed

Address duplication of paths between rdctl and typescript paths module #3652

adamkpickering opened this issue Dec 16, 2022 · 1 comment · Fixed by #4160
Assignees
Milestone

Comments

@adamkpickering
Copy link
Member

When factory reset functionality was moved into rdctl, this required duplication of the code Rancher Desktop uses to track which directories are used for what, i.e. config, application data and cache data. It isn't good to have more than a single source of truth, so this issue is about correcting this.

If I understood correctly, @jandubois suggested that we move this info into rdctl. We can then add a command to rdctl that outputs this info. This has two benefits:

  1. The main application code can call this command on startup, thus giving it access to this info.
  2. This gives the user access to a list of the paths that Rancher Desktop touches, which should more or less address Maintain list of files that rancher desktop attempts to open #2710. We should be careful to be specific about this list though - is it a complete list of the paths that RD touches, or is it limited to the directories we need to delete when doing a factory reset (the latter would exclude things like /var/run/docker.sock)?

Another possibility is to introduce a static file that is incorporated, separately, in the builds for rdctl and the main application. This would be similar to pkg/rancher-desktop/assets/dependencies.yaml.

@adamkpickering adamkpickering added this to the Next milestone Dec 16, 2022
@mook-as
Copy link
Contributor

mook-as commented Dec 16, 2022

Another possibility is to create another executable in resources/<platform>/internal that imports the same (golang) packages that rdctl does, and use that (without making it public API in the process).

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

Successfully merging a pull request may close this issue.

3 participants