For the pyproject.toml, you can keep it for another PR, it's already in the plans to switch to it, but neither of us had time to learn about it yet! If you are used to it, we'll gladly accept a first implementation 😄
When building, there is a warning saying pip version 23 will enforce it, ie something like

DEPRECATION: xxxxxxx is being installed using the legacy 'setup.py install' method, because it does not have a 'pyproject.toml' and the 'wheel' package is not installed. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found at pypa/pip#8559

So we'll need to go to it a way or another.

@echoix that's the reason I put the note in the 1st line NOTE: pyproject.toml and poetry is just for my dev env, will remove on ready PR - so do not worry about these files for now :)
I can prapare PR with pyproject.toml and poetry in the future, poetry with venv changed my life ;)

Yeah, Poetry is great!

@nvuillam +/- this PR is ready, minor cleanup, and changes left, but have Q around REPOSITORY_GITLEAKS_PR_COMMITS_SCAN. Currently, it is false but happy to put true as default because then validate all code base = false will does the job without any extra envs. But this is a kind of braking change and may impact current users' setup.
So, I'm happy to hear feedback and design decisions.

@DariuszPorowski it looks great, i'll check that tomorrow, thanks for the PR:)

Cc @Kurt-von-Laven @bdovaz @echoix

@nvuillam no rush, take your time. Tomorrow I am off so will continue on Thursday.

@nvuillam just following up :)

@DariuszPorowski you have many failing test cases ^^

@nvuillam +/- this PR is ready, minor cleanup, and changes left, but have Q around REPOSITORY_GITLEAKS_PR_COMMITS_SCAN. Currently, it is false but happy to put true as default because then validate all code base = false will does the job without any extra envs. But this is a kind of braking change and may impact current users' setup.
So, I'm happy to hear feedback and design decisions.

@nvuillam actually follow up was on this question not on the code hehe ;)

@DariuszPorowski if it breaks existing config of ML using gitleaks and VALIDATE_ALL_CODEBASE=false , i'd prefer to stay deactivated by default, to avoid a breaking change like u said ^^

@nvuillam I'm sorry it took so long but the last month has been hectic at work. PR ready for review :)

@DariuszPorowski same here, I understand 🤣

Your PR looks great but I have some doubts about the documentation... it seems you directly updated generated markdown file https://github.com/oxsecurity/megalinter/blob/cff15a01ef2d29d904b97b268df8b54225429b4a/docs/descriptors/repository_gitleaks.md , so the next time the doc will be rebuilt, it will be overwritten

If you want "free text" doc to be added, you need to update linter_description property in the YML descriptor file :)

You can verify that by yourself using bash build.sh --doc locally

@DariuszPorowski Same remark about custom variables: if you add them in the descriptor, they will be automatically added to the doc & json schema ^^

@nvuillam Oh gosh, the last changes to te main were painful to integrate with this PR :D hope now is good, docs generated automatically

@DariuszPorowski i can assure you they were even harder to implement 😅

But it's for the better good: with next version you'll just have to trust MegaLinter core code with your env variables (including secrets defined in CI/CD), no need anymore to trust the dozens of embedded linters 😎

@DariuszPorowski plz can u merge main in your branch ? :)

Sure, will do over the weekend

I did it :)