Remove websockets-client dependency

[forslund]

Description

The websocket client dependency is now handled by mycroft-messagebus-client and not needed here anymore.

Contributor license agreement signed?

CLA [ Yes ]

[devops-mycroft]

Voight Kampff Integration Test Failed (Results).
Mycroft logs are also available: skills.log, audio.log, voice.log, bus.log, enclosure.log

[devops-mycroft]

Voight Kampff Integration Test Succeeded (Results)

[clusterfudge]

I believe that it's a common practice (citation needed) to include transitive dependencies in a requirements.txt file, for the purpose of pinning fixed conflicts (as well as simple population via pip freeze). A model that's starting to gain some traction is "requirements.in + requirements.lock", where .in captures your direct dependencies, and .lock captures locked versions of the entire dependency graph. There's a decent write-up here.

[ChanceNCounter]

I'm not sure that's a concern for software that's meant to be in a virtual environment. 2nd+ degree dependencies will go away with the venv, if it's nuked and recreated, and unfrozen deps upstream would need the stars to align to hit users.

It wouldn't hurt, but it's extra dev steps to avoid a situation that would arise if, and only if, a user re/installed from scratch, while a dep is broken due to breaking changes in an unfrozen dep of its own, before either MycroftAI or Mycroft's dep notice and freeze the problem package.

[kjcole]

I believe that it's a common practice (citation needed) to include transitive dependencies in a requirements.txt file, for the purpose of pinning fixed conflicts (as well as simple population via pip freeze). A model that's starting to gain some traction is "requirements.in + requirements.lock", where .in captures your direct dependencies, and .lock captures locked versions of the entire dependency graph. There's a decent write-up here.

FWIW, I've grown quite fond of pipenv and, following the write-up you pointed to links to Overview of python dependency management tools which also seems to endorse pipenv, as well as poetry...

[forslund]

I do think the versioned package control is important to keep control over exact versions and the pip-compile looks quite useful especially for creating repeatable builds.

In this specific case the version of mycroft-messagebus-client keeps a locked version of the websocket-client and it shouldn't need to be here as well.

Renaming the requirements.txt to requirements.in in the future and adding the .lock file sounds like a good idea. dev setups just need to worry about the .in file while the packagings for mark-1 and mark-2 can make use of the .lock file to make the builds 100% repeatable. Previously pipenv has also been discussed as a possible improvement and seems like it would accomplish the same task.

[clusterfudge]

Ok, it sounds like y'all are pretty thoughtful on the topic, so please consider my commentary non-blocking! Happy to see us make improvements in the future.

[forslund]

Closing this in favor of #2879