Open wbalmer opened 4 months ago
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.
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 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)
Seems like it is not finding the file:
FileNotFoundError: [Errno 2] No such file or directory: 'webbpsf_ext.wext_style'
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?
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.