Use test env for pre-commit tests

[mahendrapaipuri]

• Use jupytext available in current test environment to execute pre-commit hooks in tests.
• This avoids creating a new environment and install jupytext in that environment.

Fixes #1210

[github-actions[bot]]

Thank you for making this pull request.

Did you know? You can try it on Binder: or .

Also, the version of Jupytext developed in this PR can be installed with pip:

pip install git+https://github.com/mahendrapaipuri/jupytext.git@fix_precommit_test

(this requires nodejs, see more at Developing Jupytext)

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 97.66%. Comparing base (12644e1) to head (4c1273b).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #1214 +/- ## ========================================== - Coverage 97.75% 97.66% -0.09% ========================================== Files 29 29 Lines 4463 4463 ========================================== - Hits 4363 4359 -4 - Misses 100 104 +4 ``` | [Flag](https://app.codecov.io/gh/mwouts/jupytext/pull/1214/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=Marc+Wouts) | Coverage Δ | | |---|---|---| | [external](https://app.codecov.io/gh/mwouts/jupytext/pull/1214/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=Marc+Wouts) | `75.21% <ø> (+0.06%)` | :arrow_up: | | [functional](https://app.codecov.io/gh/mwouts/jupytext/pull/1214/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=Marc+Wouts) | `88.48% <ø> (ø)` | | | [integration](https://app.codecov.io/gh/mwouts/jupytext/pull/1214/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=Marc+Wouts) | `77.28% <ø> (ø)` | | | [unit](https://app.codecov.io/gh/mwouts/jupytext/pull/1214/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=Marc+Wouts) | `66.55% <ø> (ø)` | | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=Marc+Wouts#carryforward-flags-in-the-pull-request-comment) to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[mahendrapaipuri]

@mwouts I think these changes should make pre-commit tests work without node. Basically with these changes, we will use jupytext in the same test environment without having to create a identical environment by pre-commit. This will accelerate tests as well as we pre-commit will not create environment for jupytext.

I think CI is failing due to this issue.

[mahendrapaipuri]

@mwouts So, except for test with pandoc==2.16.2, all of them are passing with new provisioned environment. As this failing test needs a very specific version of nbformat==5.0.8 it is failing as provisioned environment does not have this version of nbformat. Is this test still relevant? I see this will run only on conda tests as only conda envs have pandoc installed. Maybe a way is to pin nbformat==5.0.8 in conda env file to have correct version before testing?

I dont really see how we can env var HATCH_BUILD_HOOKS_ENABLE=false when pre-commit is creating envs. We can set env vars when pre-commit hooks are being executed but not during installation of envs.

[mwouts]

Hi @mahendrapaipuri , sorry it took me so long to come back to this PR (BTW I have updated the version of pandoc used in tests).

I think my concern is really about allowing the installation of jupytext in a pre-commit environment without having to compile the extension/without requiring nodejs.

I wondered if we could infer that jupytext is being installed by pre-commit based on the path to Python (I see that the Python used by the pre-commit install command is something like /home/marc/.cache/pre-commit/repopns_10q_/py_env-python3.12/bin/python, but that is arguably very hacky, and in addition I have no idea how to detect that in pyproject.toml).

I also wondered if we could use the skip-if-exists flag in [tool.hatch.build.hooks.jupyter-builder] and provide a pre-build extension in the repo itself, or whether more generally we could provide a pre-build version of Jupytext (like those on pypi) for the pre-commit install step.

[mahendrapaipuri]

I think my concern is really about allowing the installation of jupytext in a pre-commit environment without having to compile the extension/without requiring nodejs.

If we set enable-by-default = false, it will not build extension by default. Then, we will have to change everywhere relevant in CI to explicitly set env var HATCH_BUILD_HOOKS_ENABLE=true pip install . to build the extension. This approach would work with pre-commit environment but it will have global effect and we need to clearly mention that in docs.

Rest of techniques involve very huge hacks and that can potentially introduce unwanted side effects on whole jupytext package.

The real question we need to ask is if this one test so important that we need to change the behaviour of entire package? If it is, can we pin the version of nbformat==5.0.8 in conda environment.yml so that there is no need to install jupytext in pre-commit tests as we can directly use provisioned conda environment. This will speed up tests as well. Moreover, we are already testing the package with "latest" nbformat in pip tests.

[mwouts]

Thanks @mahendrapaipuri ! Yes much better to take the time to think about this. I am not concerned about the tests being slow (although I like this PR that makes them faster!), and I think we should be ready to drop the dependency on nbformat (I will address that soon).

The issue that I really want to address is https://github.com/mwouts/jupytext/issues/1210, i.e. Jupytext's pre-commit install fails when node is not available. And when node is available, the pre-commit hook is slow to install (which is why we had this conversation about these tests). I think that the proper fix would be to just no compile the extension when Jupytext is installed as a pre-commit hook, but so far I don't see yet how to achieve that (except by looking at the path for the python executable, and again I don't know how to deactivate the extension dynamically...)

[mahendrapaipuri]

Ahhh, I see what you mean. I thought you were always talking about the pre-commit unit tests. But now I see that you are more worried about using jupytext in the pre-commit hook. Sorry for the miscommunication!!

Yes, I agree with you that jupytext should not have to build extension when using in the pre-commit hook. However this is the inconvenience of having a monorepo approach. I don't see any easy way to hack this around just for pre-commit hooks.

A straightforward way is to disable extension building by default as I mentioned in my previous comment. Do you see any issues with disabling extension building by default? Another solution is to split the extension into a separate repo!