Conflicting requirements for pyobjc-core are breaking developer setup

Development
1

Running scripts/setup from dev branch HEAD fails with

Installing collected packages: homeassistant
  Attempting uninstall: homeassistant
    Found existing installation: homeassistant 2022.12.0.dev0
    Uninstalling homeassistant-2022.12.0.dev0:
      Successfully uninstalled homeassistant-2022.12.0.dev0
  Running setup.py develop for homeassistant
Successfully installed homeassistant

[notice] A new release of pip available: 22.2.2 -> 22.3.1
[notice] To update, run: pip install --upgrade pip
Traceback (most recent call last):
  File "/Users/jorhett/src/ha/venv/lib/python3.10/site-packages/pkg_resources/__init__.py", line 581, in _build_master
    ws.require(__requires__)
  File "/Users/jorhett/src/ha/venv/lib/python3.10/site-packages/pkg_resources/__init__.py", line 909, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/Users/jorhett/src/ha/venv/lib/python3.10/site-packages/pkg_resources/__init__.py", line 800, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (pyobjc-core 8.5.1 (/Users/jorhett/src/ha/venv/lib/python3.10/site-packages), Requirement.parse('pyobjc-core>=9.0'), {'pyobjc-framework-Cocoa'})

The reason is a fairly simple conflicting set of requirements. You can’t ask for >= 8.5.1 < 9.0 and also >= 9.0

$ grep -rH pyobjc-core .
./venv/lib/python3.10/site-packages/bleak-0.19.2.dist-info/METADATA:Requires-Dist: pyobjc-core (>=8.5.1,<9.0.0); platform_system == "Darwin"
./venv/lib/python3.10/site-packages/pyobjc_framework_libdispatch-8.5.1.dist-info/METADATA:Requires-Dist: pyobjc-core (>=8.5.1)
./venv/lib/python3.10/site-packages/pyobjc_framework_Cocoa-9.0.dist-info/METADATA:Requires-Dist: pyobjc-core (>=9.0)
2

Same issue here. If you’re just looking to get up and running, this is the patch that worked for me.

diff --git a/homeassistant/components/bluetooth/manifest.json b/homeassistant/components/bluetooth/manifest.json
index f81e1324da..110398f719 100644
--- a/homeassistant/components/bluetooth/manifest.json
+++ b/homeassistant/components/bluetooth/manifest.json
@@ -6,8 +6,8 @@
   "after_dependencies": ["hassio"],
   "quality_scale": "internal",
   "requirements": [
-    "bleak==0.18.1",
-    "bleak-retry-connector==2.1.3",
+    "bleak==0.19.5",
+    "bleak-retry-connector==2.8.5",
     "bluetooth-adapters==0.6.0",
     "bluetooth-auto-recovery==0.3.3",
     "dbus-fast==1.24.0"
diff --git a/homeassistant/package_constraints.txt b/homeassistant/package_constraints.txt
index 2f637ba61f..6014d21f86 100644
--- a/homeassistant/package_constraints.txt
+++ b/homeassistant/package_constraints.txt
@@ -10,8 +10,8 @@ atomicwrites-homeassistant==1.4.1
 attrs==21.2.0
 awesomeversion==22.9.0
 bcrypt==3.1.7
-bleak-retry-connector==2.1.3
-bleak==0.18.1
+bleak-retry-connector==2.8.5
+bleak==0.19.5
 bluetooth-adapters==0.6.0
 bluetooth-auto-recovery==0.3.3
 certifi>=2021.5.30
@@ -43,6 +43,7 @@ voluptuous-serialize==2.5.0
 voluptuous==0.13.1
 yarl==1.8.1
 zeroconf==0.39.1
+pyobjc-framework-Cocoa==8.5.1
 
 # Constrain pycryptodome to avoid vulnerability
 # see https://github.com/home-assistant/core/pull/16238
3

I’m looking for a way to not spend my available development time+attention on solving problems unrelated to what I’m working on. I reported this in a bug almost a month ago, and yet dev branch remains broken.

Why is it better for EVERY ha developer to be fixing the same problems, versus creating a CI test to ensure that setup isn’t broken?

4

Either you haven’t worked with open source software or you’re willingly being judgmental to the open source developers of the project. Either way I am not going to engage in that. Nobody owes you anything in a project you don’t pay for.

I provided you a workaround, take it or leave it. I’m not having any further discussion on the matter and I am not condoning your attitude.

5

I’ve got 30 years of open source development and contributions to other’s projects. And that comment is exceedingly rich, coming from someone with less than 100 contributions ever in their entire Github lifetime. :rofl:

Noting that a developer setup that has (in >1 years) never once worked successfully is an observation.

Also are observations that there are constant problems with

  • pre-commit failures (not from code but pre-commit setup)
  • settings in the repo that hide the pre-commit reported issues from the developer
  • zero interest or follow-through on PRs that attempt to improve the developer setup or documentation

Of note, my direct query regarding this situation got zero followup IME never-working developer setup is a significant barrier to entry - #2 by jorhett

Am I being judgemental to say that there’s little to zero interest shown by them? That would be a reasonable evaluation of the facts available.

6

Oh, yay. HA has locked this bug with the documented developer setup as

this is not something that core devs should support.

Ok, so non-working official developer documentation isn’t something core devs should support.