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

Add abetter control of where files get saved when inline_data is False #77

Open
acwooding opened this issue Jan 25, 2025 · 1 comment
Open

Comments

@acwooding
Copy link
Contributor

datamapplot.create_interactive_plot() writes a bunch of .zip files with data in them when inline_data is False, and the location to put them is modified only by offline_data_prefix ( eventually file_prefix). Using this to modify the directory location is hacky...for example, it gets called as gzip.open("{file_prefix}_point_data_{i}.zip"). This is ok (if not ideal) in some contexts, but is fragile and awkward if I want to put the data somewhere else entirely.

At a minimum, I'd suggest using a separate parameter to control the directory of the offline data that defaults to the current working directory.

As an additional thought, the .save on InteractiveFigure saves the html version of the figure to the filename parameter. It would be better if there was a more consistent way to save artifacts related to interactive figures. It's easy to save the html and the data required for it in completely different locations when using inline_data False and not bundling.

I can sort of understand why things are this way at the moment but I think a cleaner and more transparent way to save off the artifacts would be useful. I'm happy to help with sorting out what the desired behaviour might be and then implementing a PR for the changes. Just let me know.

@lmcinnes
Copy link
Contributor

The file_prefix was certainly never really meant for specifying a directory path, so yes, adding an option for that would be useful. In general the whole nature of things kind of grew organically, so if you want to take a pass at refactoring where things have ended up into something a little saner and more maintainable that would be greatly appreciated.

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

2 participants