-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Add 'play --playlist' support. Issue #27 #41
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, although I think we should change the Play()
function to better support playing albums... see my comment below. (And then you could easily sneak the --album
flag into this PR!)
internal/p/p.go
Outdated
|
||
return cmd | ||
} | ||
|
||
func p(api internal.APIInterface, query, deviceID string) (string, error) { | ||
func p(api internal.APIInterface, query, contextQuery, deviceID string) (string, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the logic here needs to be fixed to use contextQuery
internal/play/play.go
Outdated
|
||
return cmd | ||
} | ||
|
||
func Play(api internal.APIInterface, query, deviceID string) (string, error) { | ||
func Play(api internal.APIInterface, query, contextQuery , deviceID string) (string, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should pass query
and queryType
here, where queryType
is "track", "album", or "playlist". Then we can switch
on queryType
to determine if we should do internal.Search()
or a linear search through all of the user's playlists.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An internal.Search() currently returns a *spotify.track not a *spotify.album/playlist
- So we need to modify that to allow for a return on an album.
- If we do it for albums then the logic I have currently done for finding playlists can be overhauled aswel
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose we should just get rid of internal.Search()
, and instead call the API directly and return the PagingObject. Playing albums should have the same logic as playing tracks, just a different queryType
. I like your current logic for playlists though. We should keep that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logic for finding a playlist by name already exists for spotify playlist show
, so we might be able to steal that code and use it here
Co-authored-by: Brian Strauch <bstrauch24@gmail.com>
Co-authored-by: Brian Strauch <bstrauch24@gmail.com>
Co-authored-by: Brian Strauch <bstrauch24@gmail.com>
@brianstrauch - PR for commands that would show how we can use the Spotify library. The tests pass but I am not sure they are done correctly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks awesome! I was just thinking about how much I needed these changes earlier today 😄
Only two changes left to make before we merge:
- We should be passing flag values directly into the
p()
andPlay()
functions, so we can unit test all of the logic with the mock API. - Logic is duplicated between the
p()
andPlay()
functions, let's only write it once, inPlay()
.p()
can callPlay()
Co-authored-by: Brian Strauch <bstrauch24@gmail.com>
Co-authored-by: Brian Strauch <bstrauch24@gmail.com>
Co-authored-by: Brian Strauch <bstrauch24@gmail.com>
Co-authored-by: Brian Strauch <bstrauch24@gmail.com>
Co-authored-by: Brian Strauch <bstrauch24@gmail.com>
Co-authored-by: Brian Strauch <bstrauch24@gmail.com>
Co-authored-by: Brian Strauch <bstrauch24@gmail.com>
Co-authored-by: Brian Strauch <bstrauch24@gmail.com>
Co-authored-by: Brian Strauch <bstrauch24@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI: I'm merging brianstrauch/spotify#9 tonight and releasing v0.7.0... just to keep things moving. Just a few fixes left on this PR.
Hey @Threpio, how's this coming along? |
Was away for the weekend - apologies. Will have another update by this evening (CET) |
Co-authored-by: Brian Strauch <bstrauch24@gmail.com>
Co-authored-by: Brian Strauch <bstrauch24@gmail.com>
…/spotify-cli into playlist-brianstrauch#27 # Conflicts: # internal/p/p.go
…/Threpio/spotify-cli into playlist-brianstrauch#27" This reverts commit 6fdf6dd, reversing changes made to bdabdb5.
I won't be able to complete this for a week or so because of prior commitments - If you want to run with it then fire away! |
Done a couple of tests locally and it seems that all the new functionality is done correctly - Still intermittently getting the previous song shown when selecting a playlist... EDIT: |
@Threpio Thanks, I'll take a look later today! ... and no worries, squash is the default for this repo 😄 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, I'll make a few touch-ups and try to fix the issue you mentioned above! Thanks again for the PR!
Fixes issue #27
Upgraded root spotify module from v0.5.0 => v0.6.0.
Added --playlist flag to the play function that takes a playlist name and plays it.
Tests have been updated to reflect upgrade from spotify v0.5.0 -> v0.6.0
New tests required for additional features.