State of plexapi

[Hellowlol]

Hello everybody.

plexapi haven't gotten the attention it need for quite some time. PRS have been unmerged, test suite is broken.

Going forward I would like to fix this. I would like to get some input from any stakeholders (or any other for that matter) regarding this. @pkkid @blacktwin @andrey-yantsen @jjlawren

Short time plan:

• Fix any broken tests
• Release 3.4.0

Some time in a not so distant future:

• Let CI update docs.
• fix Travis upload.
• Review all tests, some are way to flaky
• Test on newer python version
• Use black as linter
• Drop python 2 in 4.0.0 and merge any breaking PRS (allow for title and unwatched filters #370)

[worried-networking]

Good to see that you're still interested in the project, awesome! The plan sounds great as well.

As for tests — one of the issues here is that we're downloading required content for the library for every run, and sometimes it's just failing. Some other times — we're unable to properly prepare the library and understand that it's basically ready...
In my other plex-related project (plex-api.rs, the API written in Rust) I've gone in slightly another way: the Plex library (the database and all the required media) is stored inside the repo, hence bootstrap is much faster and stable, but I had to sacrifice some disk space to it.

It's just a suggestion, feel free to choose the better path :)

[Hellowlol]

@andrey-yantsen thanks for the feedback. Ill stub the files to skip the download. That’s a great idea. I wonder why picked so large files..

[worried-networking]

I was young, sorry :D Feel free to steal the database from plex-api.rs, there is no copyright, the media — are just files with white noise.
You can find an example on how to bootstrap plex-server in my github actions workflow.

[pkkid]

I like the plan.

To me, getting the tests more reliable is a top priority. If those are running consistently and reliably, we can be more confident and move faster on all other changes. -- I did try to take a stab at fixing some of the flakyness in the tests. It seems during test setup when it downloads and configures the temp Plex client, it doesn't always see or register all media we are giving it. I ended up scraping work in the area because it didn't end up helping anything. I like the idea of storing test media in the repo, it's one less variable we have to worry about not working. -- Testing the tests is an annoying area because we have to push the changes to get Travis to execute the scripts. Maybe it'll feel cleaner if we do this on another branch.

Not sure what the Black linter is so I have no comments. I always use flake8.

At this point, I am all for dropping Python2 support in 4.0. I feel like this will be pretty easy actually since we already support both. It'll be pretty much deleting the compat.py file.

[Hellowlol]

@pkkid Good news. We are really close regarding the test there are just two or three more that i haven't figured out why it fails on travis as the pass on my local tests

Next up after then is to change to local files then push a release.

Black is the psf formater. Basically it reformat the code for you so its always the consistent way in all projects. https://github.com/psf/black

[pkkid]

Ahh its a formatter (not a linter). I've always been against formatters myself. My reasons mostly include violating strict rules in certain circumstances to make things more readable than a machine does. However, I do realize not everyone agrees with my personal formatting style and would be willing to submit my opinion to the opinion of others for this project. -- Can I suggest we try this on a branch so we can visually inspect its output before changing master?

[jjlawren]

Black is a very good and consistent formatter. Home Assistant (a user of plexapi) uses it across the project and even enforces black formatting in a pre-commit hook. I think I've only had to override it when also annotating linting exceptions.

[Hellowlol]

@pkkid yep

[Hellowlol]

Test pass, and I just noticed the coverage hasn’t been updated since 2017... Travis seems to create the coverage report. Does anybody know why it isn’t being uploaded?

[worried-networking]

@Hellowlol seems like it was me again: https://docs.coveralls.io/parallel-build-webhook, we need to add a web-hook to Travis' config.

[jjlawren]

Test pass, and I just noticed the coverage hasn’t been updated since 2017... Travis seems to create the coverage report. Does anybody know why it isn’t being uploaded?

Is this what we're looking for? https://coveralls.io/jobs/61530792.

It looks like a report is uploaded, but it's not being associated with the repo?

[Hellowlol]

Yep. Seems strange

[worried-networking]

Nothing strange, actually - when opening the link you can see that the project was identified successfully, but the results just weren’t “merged”.

We have “parallel” builds enabled, but Travis doesn’t send any signals to coveralls, for the latter to identify that the build is finished and it’s actually the time to combine all the received results.

The fix is covered in the docs, but I’ve failed to add the webhook when was enabling the parallel builds in coveralls.

[Hellowlol]

@pkkid Can you take a look on how we build the docs? I would like them to update automatically.

[jjlawren]

I think the open issues could use a purge. Many have been sitting open with no activity for months (or years!).