Skip to content

Add support for including and excluding drives from listing #89

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

Merged
merged 32 commits into from
Jul 24, 2025

Conversation

DenisaCG
Copy link
Member

@DenisaCG DenisaCG commented Jul 21, 2025

Add support for including and excluding specific drives from the drivebrowser listing. The functionalities are available in an integrated experience through the listed drives management dialog that can be accessed through the toolbar button.

Listed drives management dialog

Screencast.from.24.07.2025.15.36.13.webm

Remove drive command
The remove drive command is also accessible when on the context menu when right-clicking a specific drive.

Screenshot from 2025-07-24 15-36-46

@DenisaCG DenisaCG added enhancement New feature or request drivebrowser labels Jul 21, 2025
@DenisaCG DenisaCG marked this pull request as draft July 21, 2025 11:43
Copy link

Binder 👈 Launch a Binder on branch DenisaCG/jupyter-drives/excludeAndIncludeDrives

@DenisaCG DenisaCG marked this pull request as ready for review July 23, 2025 22:29
@DenisaCG DenisaCG requested a review from afshin July 23, 2025 23:41
Comment on lines +70 to +88
export async function includeDrive(driveName: string) {
await requestAPI<any>('drives/config', 'POST', {
include_drive_name: driveName
});

data = {
name: driveName,
path: driveName,
last_modified: '',
created: '',
content: [],
format: 'json',
mimetype: '',
size: 0,
writable: true,
type: 'directory'
};
return data;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
export async function includeDrive(driveName: string) {
await requestAPI<any>('drives/config', 'POST', {
include_drive_name: driveName
});
data = {
name: driveName,
path: driveName,
last_modified: '',
created: '',
content: [],
format: 'json',
mimetype: '',
size: 0,
writable: true,
type: 'directory'
};
return data;
}
export async function includeDrive(driveName: string) {
await requestAPI<any>('drives/config', 'POST', {
include_drive_name: driveName
});
return {
name: driveName,
path: driveName,
last_modified: '',
created: '',
content: [],
format: 'json',
mimetype: '',
size: 0,
writable: true,
type: 'directory'
};
}

If I understand this clearly, you rely on the success/failure of the await call and if it succeeds, you don't need its output, you just return the data value ... but where is the variable data declared?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The data object is declared here:

let data: Contents.IModel = {
name: '',
path: '',
last_modified: '',
created: '',
content: null,
format: null,
mimetype: '',
size: 0,
writable: true,
type: ''
};

It's being used for all requests to shape the data that is being sent.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this answer your question?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see, but then references might collide with each other. I don't think different API requests should be modifying a return value, though.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, so far there were no issues with this, but it's a good point! I'll look into it and I can open up a follow-up PR to refactor the code to let each function have it's own object.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at the requests file in general, I would say just return the object literals and remove this data variable altogether throughout that file. Since these are async functions, this pattern allows one request's response to clobber another's by sharing state, and we don't need to share anything here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be a separate refactor PR if you want to merge this functionality quickly or here in this branch if you prefer.

Copy link
Member Author

@DenisaCG DenisaCG Jul 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point! Looking over it now, as the requests then get called in contents.ts inside the Drive class where the data is used to emit the fileChanged signal, the code in requests .ts seems redundant. I can open up a follow-up PR to properly reactor the requests file to remove the data object.

Co-authored-by: Afshin Taylor Darian <[email protected]>
@DenisaCG DenisaCG merged commit 270e724 into QuantStack:main Jul 24, 2025
6 checks passed
@DenisaCG DenisaCG deleted the excludeAndIncludeDrives branch July 24, 2025 15:12
@DenisaCG DenisaCG linked an issue Jul 24, 2025 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
drivebrowser enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add config for including and excluding buckets
2 participants