Add to PIP repository
skjerns opened this issue · comments
I think this package is really great and helpful!
I've been using it since some time to visualize my sleep recordings, and it does a perfect job.
I think it might be worth adding to pypi, or is there any reason not to?
It is imo not a library that really benefits the community at large. A more generic implementation is already present in scipy; this is a method specially adapted to a specific type of stochastic signal. If your signal does not fit that class of processes, then you are better off just using the generic spectrogram method instead.
That said, I am glad you like it!
A more generic implementation is already present in scipy
Is that true? I thought the implementation on scipy is just using Welch? I don't see any reference to a multitaper approach.
Unless, my assumptions are wrong, I would second @skjerns motion. It certainly would make my life easier, as one of my projects depends on it, and I would like to keep my installation instructions simple.
Also, quite a few people work with MEG/EEG/LFP data, and as far as I can tell, they would all benefit greatly from using multitaper spectrograms, rather than Welch. I am certainly preaching that gospel, and slowly converting most of my collaborators (and sending them your way).
Alternatively:
Would it be interesting to integrate this into scipy?
I definitely second @skjerns and @paulbrodersen here, I think that the lspopt package is great and very relevant in the context of sleep research. While scipy.signal.spectrogram is great, it is far from the fine-grained resolution provided by lspopt (see here for example).
Integration into SciPy is also a good idea, though, I think that a pip install is probably a more viable and realistic short-term goal.
@paulbrodersen The spectrogram_lspopt method which I guess you use is actually a thin wrapper around the scipy.signal.spectrogram method. It calles the lspopt.lsp.lspopt method to get the taper windows and the corresponding weights and then calls scipy.signal.spectrogram for each taper/window and weighs the results together. In the sense that scipy.signal.spectrogram handles any window you throw at it, it is more generic. I merely do a weighted averaging of responses to different windows.
@skjerns scipy would not accept this. It is a convenience method added on top of their existing functionality, providing a very niche functionality (remember that the windows used in this method is optimal only for a very specific type of signals). For a more general multitaper solution use scipy.signal.windows.dpss. Scipy should not accept this. I wouldn't if I would have been responsible for it.
@raphaelvallat Thank you for thinking it is great. It is a Python port of Matlab code from the author of the paper cited in the readme, who was supervisor for my Master's essay, so I do not want to take all credit myself....
@paulbrodersen @skjerns @raphaelvallat Sleep and EEG data are examples of signals that could be said to belong to the class of Locally Stationary Processes, which this multitaper method caters to. The fact that you have understood this and want to use the software kind of undermines my original idea why not to publish it to PyPI: I did not want people to use this without understanding the content, just because it provided an easily accessible (i.e. easily accessible as in good scipy-API accessible) multitaper method.
My suggestion is that you vendor (Vendoring is the act of making your own copy of the 3rd party packages your project is using. Those copies are traditionally placed inside each project and then saved in the project repository.) lspopt into your applications instead depending on them. I do not think the code will change much over time, the license allows it and you will be rid of installing pip+git. Simply copy the lspopt folder into your app, import it from there and depend only on scipy instead. It is a well funded dependency; this is not.
That said, I could publish it to PyPI with no more than five minutes effort. If all of you three still think it is the best idea I will publish it, since you use it and I don't at the moment, and therefore your opinions matter more than mine.
Thank you for your detailed response @hbldh! Since it seems that all three of us rely on this package for our respective projects, it seems that it would be a waste of time to reinvent the wheel by "vendoring" your package into ours. I do think that a PyPI version would be super useful. It's also easier with regards to continuous integration and coverage. What do you think @skjerns @paulbrodersen?
@hbldh Thank you for your explanation. Regarding your other points, I think the metric that matters most when judging a piece of code is not lines of code written or how hard it would be to re-implement it but whether it is useful or not. And your package is definitely useful -- all by itself.
I agree with @raphaelvallat that vendoring would be the less desirable solution: for each one of us in the short term as we would then need to maintain a piece of code that we haven't written, and for the community at large in the long term as vendoring would invariably lead to fragmentation in the form of slightly different versions of lspopt that all seem to do similar things but maybe don't. Finally, you seem like a cool guy. I think you should get all the credit when it comes to your code, and -- personally -- I would feel pretty uncomfortable taking any of it by vendoring your package.
So put that thing on PyPI and let me buy you a beer if you ever come to Oxford!
I do understand your point of view @hbldh , I'm neutral regarding this. For me it's fine to continue with pip+git, as my package is only used internally anyway. Seeing what other "minimialistic" (but very useful) packages get added to PyPI, I'd be fine with adding lspopt. This way it's easier to find for people who need it. It took me some time to find this package to be honest. I do agree that having the package centralized has some advantage: If at any point someone would decide to implement another backend (e.g. mtspec instead scipy) to speed things up, the package could be updated much easier.
btw: just realized you're also the author of bleak, what a coincidence (and great work, once again, thanks)!
Thank you all; I wil upload it as soon as I get some spare time. I will move CI to Azure Pipelines instead of travis at the same time so I can get PyPI deployment from there as well, so it will take a bit longer than I said., Will get back to you when I get it done.
LSPopt is now available on 
pip install lspopt
That is fantastic, thank you. You are a star!