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

Create Python Package #365

Merged
merged 15 commits into from
Aug 28, 2024
Merged

Conversation

mariugul
Copy link
Collaborator

@mariugul mariugul commented Aug 11, 2024

Create Python Package

This introduces versioning of the project as a python package.

Pros:

  • Each version is an installable package
  • Resources are contained in the package (images, scripts etc)
  • Can be installed from PyPi (don't need git)
  • Easier to work with.
  • ++

This PR is still draft, I haven't tested it yet. The idea is to just move files and change them as little as possible and make the project run like before but as a python package. @vicwomg you should make an account on https://pypi.org/. See how to package here packaging-projects.

I can walk you through how to build the repo with poetry and that gives you .whl and .tar files. These can be uploaded quite easily to PyPi, but it should be your account. Then we can integrate it into CI so it gets automatically updated on features 1.X.0 and fixes 1.0.X etc.

pyproject.toml Outdated Show resolved Hide resolved
@vicwomg
Copy link
Owner

vicwomg commented Aug 12, 2024

I feel that the readme and and setup/launch scripts should still be in the project root to preserve backwards compatibility.

@mariugul
Copy link
Collaborator Author

mariugul commented Aug 12, 2024

I feel that the readme and and setup/launch scripts should still be in the project root to preserve backwards compatibility.

The readme I agree. I think it was a mistake, it's supposed to be root. Usually in GitHub I like to put in in docs/. The scripts can be in root also. One point of the package is really that the scripts aren't necessary anymore. If you wish to have them I can move them there. In time I think they become really obsolete as no one would want to do it that way.

Edit: The readme was already in root I think? I moved out the scripts. I put them in the folder that was already called scripts. Does it look good?

@mariugul
Copy link
Collaborator Author

I feel that the readme and and setup/launch scripts should still be in the project root to preserve backwards compatibility.

The readme I agree. I think it was a mistake, it's supposed to be root. Usually in GitHub I like to put in in docs/. The scripts can be in root also. One point of the package is really that the scripts aren't necessary anymore. If you wish to have them I can move them there. In time I think they become really obsolete as no one would want to do it that way.

Edit: The readme was already in root I think? I moved out the scripts. I put them in the folder that was already called scripts. Does it look good?

We could also move parts of the README regarding the scripts into the scripts/ folder as its own README and update the main README with how to use the python package. Also see the newest commit of putting README and LICENSE into docs/. I think it looks really clean. It's also possible to drop that commit.

- Move troubleshooting section to its own README.
- Move legacy installation method with scripts to
its own README in scripts folder.
- Update README with new information on
python package and cleanup.
@mariugul
Copy link
Collaborator Author

@vicwomg I pushed an example of cleaning up the READMEs a bit. See what you think. I still think the main readme is a bit messy. I think it should be easy, clean, straight forward with not too much images and feature information. You will have releases on github with all the information anyway

@vicwomg
Copy link
Owner

vicwomg commented Aug 12, 2024

We could also move parts of the README regarding the scripts into the scripts/ folder as its own README and update the main README with how to use the python package. Also see the newest commit of putting README and LICENSE into docs/. I think it looks really clean. It's also possible to drop that commit.

README in docs is probably fine, as long as github will still render it as a home page.

My concern with moving the scripts is that many users have already installed via git and assumed paths for these scripts (auto launch scripts, desktop shortcut configurations, etc). As I have already mentioned (and as you will find from many discussions) many pi users are linux newcomers and thrown off very easily by small changes.

docs/README.md Outdated
Comment on lines 40 to 47
|---------------------------------------|-----------------------------------------------------------------------------------------------|
| Raspberry Pi 3 and above | Suitable, but anything below Pi 3 will likely be too slow. |
| Raspberry Pi Desktop OS (headed) | Should be used if running with a display, as it requires a browser. |
| 32-bit Bullseye OS (recommended for Pi 3) | Recommended OS for Pi 3. |
| 64-bit Bookworm OS (recommended for Pi 4 and above) | Fine for Pi 4 and above. |
| Raspberry Pi 3 High-Res Video Playback | Pi 3 might struggle with high-res video playback, but overclocking can help. |
| Disable Screen Blanking | Disable "screen blanking" in `raspi-config` to prevent the display from turning off when idle.|
| Modern Mac, PCs, and Linux | Works fine on modern devices. |
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this column designation makes sense. The first 6 items are notes about raspberry pi.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was just an attempt at making a table instead of just having text. It's all up to you

docs/README.md Outdated
Comment on lines 56 to 58
# Setup a virtual environment (optional) (recommended)
python -m venv venv
source venv/bin/activate
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if no venv is created?

Copy link
Collaborator Author

@mariugul mariugul Aug 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then it's just installed directly in your PC environment. It should work perfectly fine, it's just easier to deal with a venv when deleting, upgrading, downgrading, changing versions etc. It doesn't clutter your PC installation. Especially important if you use the same dependencies in different python packages. That can lead to conflicts.

@vicwomg
Copy link
Owner

vicwomg commented Aug 12, 2024

Overall this looks great. It would be very nice indeed to make pikaraoke installable via pip. However, I think I'll need to pull this all down and do some thorough testing in various platforms to confirm everything is working.

It will probably cause quite a bit of initial confusion for existing pi users, but might be worth it to get releases running smoothly moving forward.

Comment on lines +60 to +62
# Install pikaraoke from PyPi
pip install pikaraoke
```
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if this is complete. Installation of ffmpeg is necessary. So is chromium and chromium-driver for raspberry pi users. Hence the install scripts.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure yeah. It's possible to embed those scripts in the package. For example something like have pikaraoke install the script in path as pikaraoke-setup:

pip install pikaraoke

# Setup pikaraoke
pikaraoke-setup

# Run pikaraoke
pikaraoke

@mariugul
Copy link
Collaborator Author

We could also move parts of the README regarding the scripts into the scripts/ folder as its own README and update the main README with how to use the python package. Also see the newest commit of putting README and LICENSE into docs/. I think it looks really clean. It's also possible to drop that commit.

README in docs is probably fine, as long as github will still render it as a home page.

My concern with moving the scripts is that many users have already installed via git and assumed paths for these scripts (auto launch scripts, desktop shortcut configurations, etc). As I have already mentioned (and as you will find from many discussions) many pi users are linux newcomers and thrown off very easily by small changes.

That's a good concern to have. Make it clear in the readme how to run it like before. You have this tagged and released already as 1.2 if I remember correctly. The only thing they need to understand is really to clone tag 1.2 and it's all the same as before.

@mariugul
Copy link
Collaborator Author

Overall this looks great. It would be very nice indeed to make pikaraoke installable via pip. However, I think I'll need to pull this all down and do some thorough testing in various platforms to confirm everything is working.

It will probably cause quite a bit of initial confusion for existing pi users, but might be worth it to get releases running smoothly moving forward.

That's a good idea. I will also test it on a pi, just haven't gotten to that yet. I know that the logo and qr code needs to be embedded as resources for example. I haven't done that yet in this PR. It was done in the original, so I will just port it. I can polish this PR a bit and test it and I will make it ready for review.

Modifies the files minimally with correct imports as well as
a few minor fixes to make it run again.
@mariugul
Copy link
Collaborator Author

mariugul commented Aug 13, 2024

@vicwomg I pushed some updates to the package. I can now run pikaraoke on my Ubuntu. Do this:

# from root repo (inside a venv)
pip install -e .

Or with poetry:

# from root repo
poetry install
poetry run pikaraoke

I have some issues with playing songs. I have a few already downloaded, those work. If I search a song, it's downloaded but doesn't play. It just goes to "song ended". Did not test on RPI, only my Ubuntu.

@mariugul mariugul marked this pull request as ready for review August 13, 2024 20:48
@mariugul
Copy link
Collaborator Author

I think it might make sense to just make this PR work inside the repo. Don't bother with PyPi just yet to simplify. That would mean you still need to clone the repo, but can install it as a package. Then we can do another PR where all the resources are packed into the package and it's stored on PyPi.

@mariugul
Copy link
Collaborator Author

@vicwomg is there anything you need from me to make this progress further?

@vicwomg
Copy link
Owner

vicwomg commented Aug 19, 2024

@vicwomg is there anything you need from me to make this progress further?

Your last message indicates that download/playback don't work, so obviously that is not mergeable. Did you want me to have a look at that? Sorry I haven't had much time to work on it

@mariugul
Copy link
Collaborator Author

@vicwomg is there anything you need from me to make this progress further?

Your last message indicates that download/playback don't work, so obviously that is not mergeable. Did you want me to have a look at that? Sorry I haven't had much time to work on it

No worries. I just tested on rpi. Same issue. I think you are quicker to diagnose the issue. It will not download and play.

@mariugul
Copy link
Collaborator Author

I loosened the versions for ffmpeg and yt-dlp and it worked. Will test some more but I think that was it.

@mariugul
Copy link
Collaborator Author

@vicwomg Made yt-dlp latest. Added to upgrade yt-dlp on all runs of pikaraoke. It needs to be newest anyway,right? Added the script setup.sh in a python way as setup_apt.py. When the package is installed it's available as just pikaraoke-setup in $PATH. See what you think

Run pikaraoke-setup after installing package.
@vicwomg
Copy link
Owner

vicwomg commented Aug 21, 2024

I spent some time trying to figure out publishing, and I think I have a release here (it's a bit behind your latest changes):
https://pypi.org/project/pikaraoke/

I had to change the target to python 3.9 (was 3.10) for it to work on the raspberry pi default installation. It does seem to install on my mac and on my pi 3 which is promising

@mariugul
Copy link
Collaborator Author

I spent some time trying to figure out publishing, and I think I have a release here (it's a bit behind your latest changes): https://pypi.org/project/pikaraoke/

I had to change the target to python 3.9 (was 3.10) for it to work on the raspberry pi default installation. It does seem to install on my mac and on my pi 3 which is promising

That sounds promising, good job! Do you have a specific lowest python version you wish to support? I know 3.8 is quite common. Security updates for 3.8 ends in october 2024 already see 3.8 lifespan. I know 3.10 introduced some nice features like match-case and being able to do var: str | None instead of using Optional. For compatibility with standard pi it sounds like 3.9 is a good lowest version?

@mariugul
Copy link
Collaborator Author

mariugul commented Aug 21, 2024

I spent some time trying to figure out publishing, and I think I have a release here (it's a bit behind your latest changes): https://pypi.org/project/pikaraoke/

I had to change the target to python 3.9 (was 3.10) for it to work on the raspberry pi default installation. It does seem to install on my mac and on my pi 3 which is promising

If you want to do some crazy tests and not screw up anything you can publish to https://test.pypi.org/. I can setup an automated workflow for the publishing in another PR. Then simply comitting feat: commit message to main would increment and publish a new minor version.

@mariugul
Copy link
Collaborator Author

I tried on my rapsberry pi 4 to install the package you published.
I did the steps below and it worked great. Granted, my pi already ran the setup step from the repo.

python -m venv venv
source venv/bin/activate
pip install pikaraoke
pikaraoke --headless

@vicwomg
Copy link
Owner

vicwomg commented Aug 22, 2024

I added a PR to your branch with the Python 3.9 requirement and to clean up some outdated documentation. If approved, you can merge into this PR.

I thought long about this, but I removed the steps to set up venv as I think they will confuse most beginner pi users and replaced them with a suggestion that they use venv if they feel its necessary and link to the official python docs on how to set one up. We'll see how many package conflicts arise, but I imagine not many.

I tried update the README to make the legacy scripts work by adding ./scripts/ path to them in the documentation, but they ultimately fail on the restructured imports. May just have to not recommend that approach for now.

Next test is to try a pip install on a Windows machine. If that goes well then I think the release plan is to push the package to PyPi as pikaraoke 1.3.0 (since it has breaking changes from 1.2). Then once it is confirmed there, merge the PR.

@vicwomg
Copy link
Owner

vicwomg commented Aug 22, 2024

I spent some time trying to figure out publishing, and I think I have a release here (it's a bit behind your latest changes): https://pypi.org/project/pikaraoke/
I had to change the target to python 3.9 (was 3.10) for it to work on the raspberry pi default installation. It does seem to install on my mac and on my pi 3 which is promising

If you want to do some crazy tests and not screw up anything you can publish to https://test.pypi.org/. I can setup an automated workflow for the publishing in another PR. Then simply comitting feat: commit message to main would increment and publish a new minor version.

More CI would be amazing! But we probably only want CI to upload to pypi when an official release is drafted, not on every master checkin.

@vicwomg
Copy link
Owner

vicwomg commented Aug 22, 2024

@vicwomg Made yt-dlp latest. Added to upgrade yt-dlp on all runs of pikaraoke. It needs to be newest anyway,right? Added the script setup.sh in a python way as setup_apt.py. When the package is installed it's available as just pikaraoke-setup in $PATH. See what you think

The setup script only works on debian-based distros, so might make sense to rename it to pikaraoke-setup-debian.

@mariugul
Copy link
Collaborator Author

I added a PR to your branch with the Python 3.9 requirement and to clean up some outdated documentation. If approved, you can merge into this PR.

I thought long about this, but I removed the steps to set up venv as I think they will confuse most beginner pi users and replaced them with a suggestion that they use venv if they feel its necessary and link to the official python docs on how to set one up. We'll see how many package conflicts arise, but I imagine not many.

I tried update the README to make the legacy scripts work by adding ./scripts/ path to them in the documentation, but they ultimately fail on the restructured imports. May just have to not recommend that approach for now.

Next test is to try a pip install on a Windows machine. If that goes well then I think the release plan is to push the package to PyPi as pikaraoke 1.3.0 (since it has breaking changes from 1.2). Then once it is confirmed there, merge the PR.

It sounds like a good plan. I will take a look at your PR. I can also test on windows, I have dual boot. In time we can set up these tests in CI also. I think that suggesting a venv is a good approach. To install in the global scope isn't that big of a deal if you have a dedicated pi for pikaraoke so I agree.

There are several strategies for packaging. I agree that 1.3.0 is a good package increment, however it's not exactly breaking changes. A breaking change is a major increment (2.0.0). It might be breaking change in the sense of installing and running pikaraoke is different but not in the features it offers as those are exactly the same 😄 just saying

@mariugul
Copy link
Collaborator Author

I spent some time trying to figure out publishing, and I think I have a release here (it's a bit behind your latest changes): https://pypi.org/project/pikaraoke/
I had to change the target to python 3.9 (was 3.10) for it to work on the raspberry pi default installation. It does seem to install on my mac and on my pi 3 which is promising

If you want to do some crazy tests and not screw up anything you can publish to https://test.pypi.org/. I can setup an automated workflow for the publishing in another PR. Then simply comitting feat: commit message to main would increment and publish a new minor version.

More CI would be amazing! But we probably only want CI to upload to pypi when an official release is drafted, not on every master checkin.

This comes down to packaging strategy!

Semantic

In semantic versioning you would increment every feature as 1.X.0 and every bugfix as 1.0.X. You can push these directly to PyPi and the expectation is that unless it's a major (X.0.0) change, then it's safe for the user to use latest pikaraoke of that major version.

Release Candidates

Another strategy is to do release candidates. Python does 1.0.0rc0 and 1.0.0rc1 etc. which isn't uncommon to publish and once you are ready to publish an actual package it can be published as 1.0.0. If release candidates are on PyPi then pip install pikaraoke will install only the latest release and not release candidate by default.

Beta/Alpha

The other two can be combined with alpha and betas. For example 1.0.0alpha0 becomes 1.0.0beta0 which becomes 1.0.0rc0 which then becomes the final release 1.0.0.

For such a small app it might be smart to do a simple strategy like basic semantic versioning. My question would be, assuming you will increment pikaraoke with semantic versioning, why would you wait to publish a package? If tests are ran on a PR and on merge, then master would be the production branch that's already tested. Just asking and not criticising! 😄

@mariugul
Copy link
Collaborator Author

@vicwomg Made yt-dlp latest. Added to upgrade yt-dlp on all runs of pikaraoke. It needs to be newest anyway,right? Added the script setup.sh in a python way as setup_apt.py. When the package is installed it's available as just pikaraoke-setup in $PATH. See what you think

The setup script only works on debian-based distros, so might make sense to rename it to pikaraoke-setup-debian.

I can do that if you wish! My idea was that apt is already only a debian-systems manager and it's sort of a more generic thing than debian. The reason being that rpi-os and Ubuntu aren't exactly Debian, they are Debian-derived while apt is the package manager for all of them.

@vicwomg
Copy link
Owner

vicwomg commented Aug 22, 2024

@vicwomg Made yt-dlp latest. Added to upgrade yt-dlp on all runs of pikaraoke. It needs to be newest anyway,right? Added the script setup.sh in a python way as setup_apt.py. When the package is installed it's available as just pikaraoke-setup in $PATH. See what you think

The setup script only works on debian-based distros, so might make sense to rename it to pikaraoke-setup-debian.

I can do that if you wish! My idea was that apt is already only a debian-systems manager and it's sort of a more generic thing than debian. The reason being that rpi-os and Ubuntu aren't exactly Debian, they are Debian-derived while apt is the package manager for all of them.

If there's a naming that makes more sense feel free to go with it. I just don't want mac and windows users running this script

@mariugul
Copy link
Collaborator Author

@vicwomg Made yt-dlp latest. Added to upgrade yt-dlp on all runs of pikaraoke. It needs to be newest anyway,right? Added the script setup.sh in a python way as setup_apt.py. When the package is installed it's available as just pikaraoke-setup in $PATH. See what you think

The setup script only works on debian-based distros, so might make sense to rename it to pikaraoke-setup-debian.

I can do that if you wish! My idea was that apt is already only a debian-systems manager and it's sort of a more generic thing than debian. The reason being that rpi-os and Ubuntu aren't exactly Debian, they are Debian-derived while apt is the package manager for all of them.

If there's a naming that makes more sense feel free to go with it. I just don't want mac and windows users running this script

That makes sense. I think apt should already describe that someone who doesn't have apt can't run it. The script is abstracted to the command pikaraoke-setup. Can make this command only work on linux. Can also in time implement so it works on mac and windows too.

@vicwomg
Copy link
Owner

vicwomg commented Aug 22, 2024

@vicwomg Made yt-dlp latest. Added to upgrade yt-dlp on all runs of pikaraoke. It needs to be newest anyway,right? Added the script setup.sh in a python way as setup_apt.py. When the package is installed it's available as just pikaraoke-setup in $PATH. See what you think

The setup script only works on debian-based distros, so might make sense to rename it to pikaraoke-setup-debian.

I can do that if you wish! My idea was that apt is already only a debian-systems manager and it's sort of a more generic thing than debian. The reason being that rpi-os and Ubuntu aren't exactly Debian, they are Debian-derived while apt is the package manager for all of them.

If there's a naming that makes more sense feel free to go with it. I just don't want mac and windows users running this script

That makes sense. I think apt should already describe that someone who doesn't have apt can't run it. The script is abstracted to the command pikaraoke-setup. Can make this command only work on linux. Can also in time implement so it works on mac and windows too.

I was referring to the abstracted command: pikaraoke-setup would prefer that it is clear this wont work on mac and windows. I'm not sure we can make it work on those platforms. It may not be trivial to add installation scripts for ffmpeg/chrome via command line.

In fact, the setup really only installs ffmpeg and chrome. We could also just communicate that in the README (in fact, I did add that in my PR to your PR)

@mariugul
Copy link
Collaborator Author

@vicwomg Made yt-dlp latest. Added to upgrade yt-dlp on all runs of pikaraoke. It needs to be newest anyway,right? Added the script setup.sh in a python way as setup_apt.py. When the package is installed it's available as just pikaraoke-setup in $PATH. See what you think

The setup script only works on debian-based distros, so might make sense to rename it to pikaraoke-setup-debian.

I can do that if you wish! My idea was that apt is already only a debian-systems manager and it's sort of a more generic thing than debian. The reason being that rpi-os and Ubuntu aren't exactly Debian, they are Debian-derived while apt is the package manager for all of them.

If there's a naming that makes more sense feel free to go with it. I just don't want mac and windows users running this script

That makes sense. I think apt should already describe that someone who doesn't have apt can't run it. The script is abstracted to the command pikaraoke-setup. Can make this command only work on linux. Can also in time implement so it works on mac and windows too.

I was referring to the abstracted command: pikaraoke-setup would prefer that it is clear this wont work on mac and windows. I'm not sure we can make it work on those platforms. It may not be trivial to add installation scripts for ffmpeg/chrome via command line.

In fact, the setup really only installs ffmpeg and chrome. We could also just communicate that in the README (in fact, I did add that in my PR to your PR)

Can call it pikaraoke-setup-apt for example for now then. I think it's not so difficult to make it work on windows/mac too, but that's for another day 😄

@vicwomg
Copy link
Owner

vicwomg commented Aug 22, 2024

Promising news, I managed to get the pip package installed on my windows box. Works as expected.

I did have to fight with the fact that python 3.8 was installed already and thus not compatible. I used the windows installer to put 3.12 on there, but pip refused to recognize the upgraded version, which caused a lot of headaches. Ultimately, I had to: delete all paths to the old 3.8 version of pip from the environment. Uninstall/Reinstall 3.12 and be sure to check the "add environment variables" setting in the installer (a custom option buried under some screens). I don't know how anyone on windows manages to use python without going crazy.

@mariugul
Copy link
Collaborator Author

Promising news, I managed to get the pip package installed on my windows box. Works as expected.

I did have to fight with the fact that python 3.8 was installed already and thus not compatible. I used the windows installer to put 3.12 on there, but pip refused to recognize the upgraded version, which caused a lot of headaches. Ultimately, I had to: delete all paths to the old 3.8 version of pip from the environment. Uninstall/Reinstall 3.12 and be sure to check the "add environment variables" setting in the installer (a custom option buried under some screens). I don't know how anyone on windows manages to use python without going crazy.

Great! I have used python on windows and I did go crazy 🤣 Awesome to hear that it worked! 📦 🎉

@vicwomg
Copy link
Owner

vicwomg commented Aug 22, 2024

For such a small app it might be smart to do a simple strategy like basic semantic versioning. My question would be, assuming you will increment pikaraoke with semantic versioning, why would you wait to publish a package? If tests are ran on a PR and on merge, then master would be the production branch that's already tested. Just asking and not criticising! 😄

I could be in the minority, but I just tend to think of releases as a collection of bugfixes, and a version bump is tied to a release, not a checkin. Master serves as a bleeding edge sandbox, but until it's fully tested (and I consider manual QA a part of that process) a release would not be considered.

If it is simpler to semantic bump on every merge, we can try it that way and see if it becomes unwieldy. You're right that master commits are relatively rare now. My hope is more maintainers (I hope you'd be interested in that role!) would join the project and it becomes more common.

@mariugul
Copy link
Collaborator Author

For such a small app it might be smart to do a simple strategy like basic semantic versioning. My question would be, assuming you will increment pikaraoke with semantic versioning, why would you wait to publish a package? If tests are ran on a PR and on merge, then master would be the production branch that's already tested. Just asking and not criticising! 😄

I could be in the minority, but I just tend to think of releases as a collection of bugfixes, and a version bump is tied to a release, not a checkin. Master serves as a bleeding edge sandbox, but until it's fully tested (and I consider manual QA a part of that process) a release would not be considered.

If it is simpler to semantic bump on every merge, we can try it that way and see if it becomes unwieldy. You're right that master commits are relatively rare now. My hope is more maintainers (I hope you'd be interested in that role!) would join the project and it becomes more common.

There are different strategies and approaches. I haven't seen this one so much. What I suggested would be a Continuous Deployment (CD) with Continuous Integration (CI) strategy which is an agile concept. I'm sure you are familiar. However, you raise a point with what master is supposed to be. That would be the branching strategy. GitFlow is a popular one with development branch and master branch. It's quite complex and a bit outdated. GitHub advocates for github flow which is simpler and made to work with CI/CD. In this strategy master branch is always in a deployable state and all code is integrated before merge.

I don't think your strategy is bad, I just think it's not the best for a small app like this and not so agile. I would vouch for good tests (don't have it yet) that integrate code so when it reaches master it's always seen as deployable.

As you say, we could always try and see how it goes. I could probably help out with maintaining.

@vicwomg
Copy link
Owner

vicwomg commented Aug 26, 2024

Inching forward on this. Pushed the latest to pypi, but noticing a couple of things on the pi.

  • One cannot install without virtualenv without the dire This environment is externally managed warning and overriding with --break-system-packages which seems unadvisable. After merging this I may try to find a solution that is simpler for beginner pi users (pipx?) I feel that venv commands are difficult to remember for the average user. https://stackoverflow.com/questions/75608323/how-do-i-solve-error-externally-managed-environment-every-time-i-use-pip-3
  • This is not the fault of any new code, but the pi3 seems to underperform significantly. Noticing some tracks getting skipped and never played. It appears to be a due to CPU maxing out.

@mariugul
Copy link
Collaborator Author

mariugul commented Aug 26, 2024

Inching forward on this. Pushed the latest to pypi, but noticing a couple of things on the pi.

  • One cannot install without virtualenv without the dire This environment is externally managed warning and overriding with --break-system-packages which seems unadvisable. After merging this I may try to find a solution that is simpler for beginner pi users (pipx?) I feel that venv commands are difficult to remember for the average user. https://stackoverflow.com/questions/75608323/how-do-i-solve-error-externally-managed-environment-every-time-i-use-pip-3
  • This is not the fault of any new code, but the pi3 seems to underperform significantly. Noticing some tracks getting skipped and never played. It appears to be a due to CPU maxing out.

Great! Yes installing directly with pip can give these warnings. I think that installing a python package inside a venv is python101 and not crazy to expect. With some quick trying I think that pipenv might be the simplest way.

pip install pipenv
pipenv install pikaraoke
pipenv run pikaraoke

Could also use pipx like this, but I think it's more difficult to install pipx itself correctly.

python3 -m pip install --user pipx
python3 -m pipx ensurepath
pipx install pikaraoke
pikaraoke

I think that poetry is not great for direct installation from PyPi. A simple venv is nice because it comes as a python builtin already. Could always list the different ways.

Honestly it's like 3 or 4 commands that people can copy from a readme to the terminal. It should be ok no matter which method you recommend.

@vicwomg vicwomg merged commit b9ef030 into vicwomg:master Aug 28, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants