use the lock file for pinning dependencies, not the project definition

[altendky]

Purpose:

Presently every dependabot PR that updates a package we have specified in pyproject.toml conflicts because the poetry.lock has a hash of the contents of pyproject.toml. There's various discussion that could be had around * vs. >=x.y.z vs. ^x.y and specifying versions here or there or wherever... but we can't be dealing with these conflicts every time so some option involving not changing pyproject.toml every time is needed.

With this change it is reasonable once again to have dependabot auto-rebase since the PRs won't all be conflicting.

Current Behavior:

New Behavior:

Testing Notes:

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[arvidn]

as I understand the poetry documentation, we would want to use ^ instead of >=.
https://python-poetry.org/docs/dependency-specification/

[altendky]

I personally started with * since we have no particular ties the the version we are exactly pinning now. I switched to >= since Earle asked for it. There's doubt in the Python community that upper version limits actually net a better ecosystem. Yeah, SemVer, I'm all about it. But, if you strictly follow it then you can end up with many major version bumps over minor corner case fixes that won't affect the vast majority of dependees. Then some of those dependees aren't really well maintained and have upper version limits. Then nobody can install anything sensible anymore. The flip side is more accidental breakage... but. Anyone can add a constraint (an upper limit for a package) while nobody can take an existing constraint away from a package they don't own (like an upper limit). And yes, there are issues talking about adding the ability to override other package's dependency constraints. :]

So yes, we could ^ if we wanted to constrain the upper bound. Given that we have a lock and require PRs, we'll be testing every update to the lock the same regardless of it being major, minor, or patch and also regardless of what constraint we use here.

There are cases, like a user needing to do a local version update for whatever reason, where better describing our limits of compatibility would be good. Today, we provide no guidance on that since we pin version in both the lock and the project definition. So, I'm not clear that just dropping the constraints in the project definition makes things particularly worse.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[coveralls-official]

Pull Request Test Coverage Report for Build 11072836265

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 37 unchanged lines in 7 files lost coverage.
• Overall coverage remained the same at 90.958%

---

Files with Coverage Reduction	New Missed Lines	%
chia/data_layer/data_store.py	1	95.64%
chia/_tests/core/full_node/test_transactions.py	1	99.14%
chia/wallet/util/wallet_sync_utils.py	1	86.54%
chia/plotters/madmax.py	1	50.6%
chia/rpc/rpc_server.py	4	87.83%
chia/wallet/wallet_node.py	7	88.15%
chia/_tests/core/util/test_lockfile.py	22	77.73%

Totals
Change from base Build 11060322104:	0.0%
Covered Lines:	102031
Relevant Lines:	112151

---

💛 - Coveralls

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This PR has been flagged as stale due to no activity for over 60 days. It will not be automatically closed, but it has been given a stale-pr label and should be manually reviewed by the relevant parties.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.