Request to not pin dependencies

[allenporter]

It would be super helpful if this project did not pin required dependencies to specific versions. The common symptom is that basically if downstream projects are ahead then we'll see errors like this:

The conflict is caused by:
    The user requested pytest-asyncio==0.23.7
ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts
    pytest-homeassistant-custom-component 0.13.124 depends on pytest-asyncio==0.23.6

I understand why it may be useful to block major versions of pytest or something or known bad issues, so that is ok, but minor version pinning is too strict.

(My impression is this happens because this project shared dependencies between setup and dev. Its usually fine to pin dependencies for dev -- i do this also -- but left the required packages in setup.py drift with a minimum version).

Thank you for maintaining this great library, i use this in nearly all of my home assistant related projects.

[MatthewFlamm]

This project uses the exact same testing versions as homeassistant for that version of homeassistant. Why would you want to be ahead of homeassistant?

[allenporter]

I use automated dependency updates like renovatebot/mend. It will run tests via CI though and fail if something is broken and not merge the update. This is pretty common for lots of projects and its done on the development updates to be prepared for moving to newer releases.

(We also could talk more about moving ahead with pre-release versions of home assistant though. It's nice to have things working before releases happen, though i know it can be churny)

[MatthewFlamm]

The downside of this approach is that most users probably want to test with the versions that are known to work with homeassistant for that version they are testing. I often find that homeassistant tests will only work on specific versions of the test dependencies, and I fear there will be more issues raised here if we don't pin. Is there a way to accomplish both goals?

(We also could talk more about moving ahead with pre-release versions of home assistant though. It's nice to have things working before releases happen, though i know it can be churny)

This project tries to release a version for every pre-release version. See https://github.com/MatthewFlamm/pytest-homeassistant-custom-component/releases/tag/0.13.126 as an example.

[allenporter]

The downside of this approach is that most users probably want to test with the versions that are known to work with homeassistant for that version they are testing. I often find that homeassistant tests will only work on specific versions of the test dependencies, and I fear there will be more issues raised here if we don't pin. Is there a way to accomplish both goals?

I would be surprised if that happens for minor patch releases.

This project tries to release a version for every pre-release version. See https://github.com/MatthewFlamm/pytest-homeassistant-custom-component/releases/tag/0.13.126 as an example.

OK, that sounds right. (I was doing pre-pre-release this time since i'm helping with some of the new AI feature, but realize that is not common)

[allenporter]

I also just noticed this on one of my systems:

ERROR: Could not find a version that satisfies the requirement mypy-dev==1.10.0a3 (from pytest-homeassistant-custom-component) (from versions: 1.9.0b1, 1.10.0b1, 1.11.0a1, 1.11.0a2, 1.11.0a3, 1.11.0a5)

So a mypy-dev version is pinned... that version doesn't exist anymore or something? Not sure that we're getting lots of value from having specific pins like this, but now i'm going to have to upgrade anyway to a new pinned version.

[MatthewFlamm]

This might be caused by this line, which we definitely do not need:

pytest-homeassistant-custom-component/requirements_test.txt

Line 10 in 741bbea

-r requirements_test_pre_commit.txt

[MatthewFlamm]

I would be surprised if that happens for minor patch releases.

I think this is besides the point, but this package history shows that not infrequently a patch release has significant testing changes that require reconfiguring the extraction code, let alone significant changes in testing library versions.

[pnbruckner]

I also just noticed this on one of my systems:

ERROR: Could not find a version that satisfies the requirement mypy-dev==1.10.0a3 (from pytest-homeassistant-custom-component) (from versions: 1.9.0b1, 1.10.0b1, 1.11.0a1, 1.11.0a2, 1.11.0a3, 1.11.0a5)

So a mypy-dev version is pinned... that version doesn't exist anymore or something?

I just ran into this, too. I use this repo for automated testing of my HA custom integrations, and I use several versions to test my integrations with several versions of HA. I try to maintain backwards compatibility, at least for a while.

Anyway, this was working until just very recently. I think whoever maintains mypy-dev on pypi.org just recently dropped the 1.10.0a3 release, so now all versions of this repo, until maybe the last couple of days, no longer work. 😞

[MatthewFlamm]

Actually this is a problem in the requirements file from homeassistant itself. There really is nothing we can do here until homeassistant updates itself to fix the problem unfortunatley...

pytest-homeassistant-custom-component/requirements_test.txt

Line 14 in 741bbea

mypy-dev==1.11.0a3

[pnbruckner]

That's not really the problem. homeassistant already did update to 1.11.0a3, which does exist on pypi.org.

The problem, at least for me, is being able to test a custom integration with older versions of HA using older versions of this repo. Actually, the problem is the maintainer of mypy-dev on pypi.org might not understand that. The version needed (in my case, 1.10.0a3), although still available via the mypy-dev repo, was pulled down from pypi.org.

Possibly the real problem is homeassistant using mypy-dev in the first place. It warns "Use at your own risk!"

[MatthewFlamm]

If home assistant updated, then this package will also update once a release is made there and thus here. Again, this package is meant to be as close to homeassistant testing as possible, if there is a problem in homeassistant, then there is a problem here too.

[allenporter]

My take is that this library should probably not have an opinion on mypy versioning. Home assistant does for its own code base for running its own tests, and does not maintain a separate way to express dependencies for the core of the home assistant tests. It might make sense to limit the number of dependencies copied from home assistant dependencies. (Either allow list or deny list).

(I don't necessarily think the ha requirements test file is a problem but agree depending on mypy dev is suspect. But this project should care about hole assistants mypy preferences I think)

[MatthewFlamm]

This slipped in because we were looking for mypy and not mypy-dev

pytest-homeassistant-custom-component/generate_phacc/const.py

Line 27 in 741bbea

"mypy",