-
Notifications
You must be signed in to change notification settings - Fork 12
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
Comments
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 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 the 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. |
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). |
Just to report, I still get this issue for matplotlib = 3.8.3. |
@JarronL With a fresh installation of
|
Seems like it is not finding the file:
|
Does this happen when you simply |
I have spaceklip installed via pip dev mode (pip install -e .). I keep getting this error whenever the style file is invoked.
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.
The text was updated successfully, but these errors were encountered: