BUG: pre-commit version 4.0.0 is required

[WillAyd]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

Try to run pre-commit on main

Issue Description

It looks like the minimum pre-commit version was bumped to 4.0.0 in #61246

However, the version that gets installed by apt on Ubuntu 24.04 is only 3.6.2, so you would have to mess with the system provided version to develop on pandas, or set up a more complicated environment

Expected Behavior

The pre-commit minimum version pin should probably be a little looser @mroeschke

Installed Versions

main

[mroeschke]

We don't really advertise/support creating development environments from apt packages so I'm a little hesitant wanting to support that use case. Is there a reason you need to use pre-commit from apt?

[WillAyd]

Do you think it should be pip installed by the system installed Python instead? On Debian you are discouraged from doing so:

pip install pre-commit
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.
    
    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.
    
    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.
    
    See /usr/share/doc/python3.12/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

For sure can go through the alternatives listed above, but it would be nicer to avoid. Is there a particular feature we need the 4.0.0 min for?

[mroeschke]

Do you think it should be pip installed by the system installed Python instead?

We do also encourage development environments to be in a virtual environment, as describe in that traceback.

Is there a particular feature we need the 4.0.0 min for?

Not in particular, but I am also just not very fond on being bound to limitations of the apt ecosystem because in my experience Python library authors are usually not the ones releasing/maintaining their apt equivalents.

[WillAyd]

We do also encourage development environments to be in a virtual environment, as describe in that traceback.

Just to clarify the use case, I think this mostly will affect IDEs and editors that are not attached to a given virtual environment. In my use case, I have my IDE set up to the system pre-commit, so that I don't need to putz around with every single project to make a commit, and can work multiple projects from a single session.

pre-commit will create its own virtual environment separate from the virtual environment you use for development anyway, so it doesnt affect the functionality of the checks by using a system installed package

[mroeschke]

Yeah your convenience use case is understandable, but would still be -0 to change (but won't die on that hill) due to apt not being in lockstep with pypi/conda generally.

[rhshadrach]

In my use case, I have my IDE set up to the system pre-commit, so that I don't need to putz around with every single project to make a commit

I'm a little confused here. Are you not using a virtual environment when working on pandas, and if you are, are you needing to do anything more than pip install pre-commit in that virtual environment?

[WillAyd]

I use a virtual environment for working on pandas, but for committing files to git and running git hooks I just use my IDE directly, which doesn't need to be launched from or activate the virtual environment

[rhshadrach]

I see - thanks. Though I do agree with @mroeschke - I don't think we should be holding back dev tools because a developer wants to do dev-related activities with the system's installation of Python.

[WillAyd]

I suppose it depends how you look at it. I don't consider anything from my setup to be using system Python for development. I am just using system libraries to commit to the VCS (namely git and its pre-commit ecosystem, within which there is a popular Python package of the same name)

[rhshadrach]

Ah, indeed - apologies. I'd be opposed to the policy of holding back dev tools for any contributor, but I think perhaps core-devs deserve more consideration. If there is a feature we want to use or bug we're impacted by, then I'd also be opposed. But barring that, I'm okay to hold pre-commit back.

[behrenhoff]

I am also using a (user-)global pre-commit installation for simplicity. However, you can just remove the older version from apt and install pre-commit via uv tool install pre-commit instead. I do the same for ruff. Solves all problems.

Global installs of pre-commit and tools like ruff are useful especially when working in multiple different projects of varying quality.