Allow installing the plugin with pylint v4

[webknjaz]

Currently, depresolvers will just fail. But this allows installing newer pylint with this plugin. Let's see what the CI has to say about it...

[webknjaz]

(dev.txt needs to be regenerated for the CI to show us the compat)

[webknjaz]

@stdedos looks like you also need to approve the CI run?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.24%. Comparing base (1bf53a3) to head (ddd4b4a).
⚠️ Report is 7 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #129   +/-   ##
=======================================
  Coverage   98.24%   98.24%           
=======================================
  Files          20       20           
  Lines         571      571           
  Branches      108       66   -42     
=======================================
  Hits          561      561           
  Misses          8        8           
  Partials        2        2           

Flag	Coverage Δ
3.10	98.24% <100.00%> (ø)
3.11	98.24% <100.00%> (ø)
3.12	98.24% <100.00%> (ø)
3.13	98.24% <100.00%> (?)
3.14	98.24% <100.00%> (?)
3.8	?
3.9	?
macos-latest	98.24% <100.00%> (ø)
ubuntu-latest	98.24% <100.00%> (ø)
windows-latest	98.24% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[webknjaz]

@stdedos I recommend storing a plain text Codecov token in the repo. It's not that secret but it improves upload stability. Alternatively, try the web UI setting for tokenless uploads in API v5.

[prousso]

Do you have some news 🙏
This PR solves our issue and allows to use pylint4

[stdedos]

It is under work (albeit slowly) 😓

[stdedos]

@webknjaz anything negative-interesting you are seeing?

Idk what resulted in this PR, but - do you want to try an editable install and see "if it works"?

[webknjaz]

Urgh.. didn't we fix None in pip-tools? I thought we did. Have you tried the latest version?

Suggested change

	# pip-compile --cert=None --client-cert=None --generate-hashes --index-url=None --max-rounds=20 --output-file=requirements/dev.txt --pip-args=None --strip-extras pyproject.toml requirements/dev.in
	# pip-compile --generate-hashes --max-rounds=20 --output-file=requirements/dev.txt --strip-extras pyproject.toml requirements/dev.in

The settings can live in a .pip-tools.toml, by the way.

[stdedos]

Given #132, I'll ... ignore this 🙏

[webknjaz]

uv also has subcommands for pip-tools. I wouldn't be surprised if it can respect these settings. I'm not moving to it for everything, maybe for a few select features. I'd rather wait until more ecosystem can install from pylock and make sure to always export into a standardized format rather than the vendor-locked one.

[stdedos]

... tbh, I wouldn't be interested to switch either.

But recently I've used it, and ... it is SO MAGICAL, yet so well-behaved 😊

... I don't like the "mess" that lockfiles cause (and the complexity that other tools cause in my eyes - like hatchling, poetry) - but (a) EVERYTHING moves towards lockfiles, and I like how uv behaves.

At least I can "wrap this complexity up" with one tool, that is "well supported", and (for the time being) has ppl to ask Qs one gh issue away 🙏

[webknjaz]

There be dragons, though. Just well-hidden. The interpreters have known quirks. The depresolver takes shortcuts based on not-always-true assumptions that may hit you later than the deptree is computed (same as poetry, this may be influenced by pubgrub, I imagine; pip could do it too if it didn't care about correctness). The ecosystem highly focuses on monorepos etc.

pip is able to output pylock since the spring, about to be able to install from them. In pip-tools, we're tracking them as well but haven't had a chance to dedicate time to implementing. We fixed the maintenance situation last year, through.

Lock files are great. The only problem is that they are often misunderstood. UV makes things look nice but I don't know if it's capable of handling env separation correctly. Though, as long as you export to pylock files in addition to whatever uv is doing, this should be friendly to arbitrary contributors who might prefer standard-compliant tooling.

[stdedos]

... sounds like a simple fix: https://docs.astral.sh/uv/concepts/projects/layout/#relationship-to-pylocktoml

[stdedos]

Have you tried the latest version?

Now I started understanding wdym by that. I guess the answer is no (

pylint-pytest/Makefile

Line 11 in 7271ecc

pip install --quiet --upgrade 'pip==24.2' 'pip-tools==7.4.1'

)

... but still #96 (AKA #132), therefore "deferring"

[webknjaz]

@stdedos I don't think I'll be able to test this anytime soon but I looked at the diff and haven't noticed anything immediately suspicious. So it should be fine to merge.

[noirbee]

FWIW using this branch lets one install and run pylint v4+, i.e.

pylint>=4
git+https://github.com/webknjaz/pylint-pytest-1.git@patch-1

Is accepted by pip-compile / uv pip compile. No particular issues running pylint / the plugin either, which can be expected since the actual code changes are mostly cosmetic.

[stdedos]

Thank you for starting this @webknjaz, and @noirbee for the additional testing 😊 🎉 🎉