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

oserror with spaceKLIP.sk_style #172

Open
wbalmer opened this issue May 13, 2024 · 6 comments
Open

oserror with spaceKLIP.sk_style #172

wbalmer opened this issue May 13, 2024 · 6 comments
Labels
bug Something isn't working

Comments

@wbalmer
Copy link
Collaborator

wbalmer commented May 13, 2024

I have spaceklip installed via pip dev mode (pip install -e .). I keep getting this error whenever the style file is invoked.

OSError: 'spaceKLIP.sk_style' is not a valid package style, path of style file, URL of style file, or library style name (library styles are listed in `style.available`)

Not sure if this is a path issue on my end or something weird happening with my matplotlib install, or a bug others have encountered. As someone who prefers to define my own style using my personal style file, I also just take issue with this being baked into spaceklip, because I have to comment/uncomment it out whenever I pull or push stuff.

@JarronL
Copy link
Collaborator

JarronL commented May 13, 2024

I think you need matplotlib >=3.7.1 for style files to load correctly from packages.

You can test by doing one of these:

# To use: 
plt.style.use('spaceKLIP.sk_style')`

# Or
with plt.style.context('spaceKLIP.sk_style'):
    some_plot_function1()
    some_plot_function2()
    some_plot_function3()

# This also works:
@plt.style.context('spaceKLIP.sk_style')
def plotting_function(*args, **kwargs):
    plt.plot(*args, **kwargs)

So, the spaceKLIP style file shouldn't be modifying anything outside of this package, but most of the internal functions utilize the with plt.style.context('spaceKLIP.sk_style'): that makes it unavoidable for the internal functions at the moment.

I agree that we can probably think of a better way of implementing (or not) the spaceKLIP plotting style. The history is that before such style files existed, I had integrated something into pynrc for myself (before it was publicly available), which then translated over to webbpsf_ext [the original sin]. As a dependency to spaceKLIP, some of those settings got edited due to how different platforms would visualize text, etc., and then the whole implementation received pushback because it was hardcoded to modify a number of matplotlib settings, which was problematic for any subsequently loaded packages. Sooo, I implemented the mpl style file scheme so that it kept the internal spaceKLIP behavior the same while not altering anything else. But that means if someone more advanced (such as yourself) was purposefully overriding the prior settings with your own style configs, that no longer works and you have no way of getting around this in spaceKLIP specific plotting functions other than to manually edit thesk_style.mplstyle file.

Perhaps the thing to do is to keep the style file there, but remove any explicit call to it, so that users could decided wether or not to utilize it through their own context manager calls.

@wbalmer
Copy link
Collaborator Author

wbalmer commented Jun 14, 2024

Thanks for the context Jarron. I suppose I selfishly prefer to remove any explicit call or context in spaceKLIP, but that might be a minority opinion, in which case I'm fine to just comment it out on my own dev branches and make do.

It seems feasible to integrate context manager calls to the spaceKLIP style file into the documentation rather than the module itself, to produce docs with the unified style, but of course that's extra work for folks currently doing documentation development (which I am not clued into).

@wbalmer
Copy link
Collaborator Author

wbalmer commented Jun 14, 2024

Just to report, I still get this issue for matplotlib = 3.8.3.

@kammerje
Copy link
Collaborator

kammerje commented Jun 26, 2024

@JarronL With a fresh installation of spaceKLIP (including the entire Conda environment), I get the following WebbPSF_ext-related error. It appears with both matplotlib==3.9.0 and 3.7.1. It seems related to the issue experienced by @wbalmer.

OSError: 'webbpsf_ext.wext_style' is not a valid package style, path of style file, URL of style file, or library style name (library styles are listed in style.available)

@kammerje
Copy link
Collaborator

kammerje commented Jun 26, 2024

Seems like it is not finding the file:

FileNotFoundError: [Errno 2] No such file or directory: 'webbpsf_ext.wext_style'

@JarronL
Copy link
Collaborator

JarronL commented Jun 26, 2024

Does this happen when you simply import webbpsf_ext? Is there a specific line number where the error is occurring? What operating system are you using?

@mperrin mperrin added the bug Something isn't working label Jul 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants