Package Details: python-pytest-recording 0.13.2-6

Git Clone URL: https://aur.archlinux.org/python-pytest-recording.git (read-only, click to copy)
Package Base: python-pytest-recording
Description: Pytest plugin to record network interactions with VCR.py
Upstream URL: https://pypi.org/project/pytest_recording
Licenses: MIT
Submitter: AchmadFathoni
Maintainer: gesh
Last Packager: gesh
Votes: 1
Popularity: 0.53
First Submitted: 2022-03-22 09:59 (UTC)
Last Updated: 2025-04-10 18:30 (UTC)

Latest Comments

1 2 Next › Last »

Drack commented on 2025-04-11 07:17 (UTC)

Hello,

When trying to update this package as of today, I got the following error:

  -> Extracting python-pytest-recording-0.13.2 with bsdtar
==> Sources are ready.
==> Making package: python-pytest-recording 0.13.2-6 (Fri 11 Apr 2025 09:13:37 AM CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Removing existing $pkgdir/ directory...
==> Starting build()...
/home/drac/.cache/yay/python-pytest-recording/PKGBUILD: line 31: cd: python-pytest-recording-0.13.2: Not a directory
==> ERROR: A failure occurred in build().

gesh commented on 2025-04-10 12:43 (UTC)

@medaminezghal I saw it, but thanks for keeping me posted on it. I've updated prepare() to use the final PR you posted for clarity's sake.

medaminezghal commented on 2025-04-10 09:57 (UTC)

@gesh In the next version there is no need to use the prepare function as the problem is fixed from the PR in the GitHub and it has merged today.

gesh commented on 2025-04-04 15:15 (UTC)

Right - I ended up using your sed solution instead of just patching using your PR as I initially intended - upstream has diverged too far since the last release for the patch to cover all the invocations it needs to.

medaminezghal commented on 2025-04-04 13:36 (UTC)

@gesh I've already done a pull requests in the GitHub

gesh commented on 2025-04-04 13:01 (UTC)

... I don't know if I invoked makepkg incorrectly before, but I'm seeing the failure now. It's surprising, I'll pull in your PR if I can't find the root problem.

Thanks for reporting this!

medaminezghal commented on 2025-04-03 19:23 (UTC)

@gesh use makepkg -sf (with installed pretty plugin) and it will fail

gesh commented on 2025-03-30 08:54 (UTC)

@medaminezghal Can't reproduce your test failure, even on a system with python-pytest-pretty installed. Please check if pkgctl build -c on your system still fails.

medaminezghal commented on 2025-03-18 08:11 (UTC)

@gesh you can add this prepare function to make the test run:

prepare(){
    # Disable pretty plugin in pytest
    cd "${srcdir}/${_src_folder}"
    sed -i 's/\(runpytest([^)]*\)/\1, "-p no:pretty"/' tests/test_blocking_network.py
    sed -i 's/\(runpytest([^)]*\)/\1, "-p no:pretty"/' tests/test_plugin.py
    sed -i 's/\(runpytest([^)]*\)/\1, "-p no:pretty"/' tests/test_recording.py
    sed -i 's/\(runpytest([^)]*\)/\1, "-p no:pretty"/' tests/test_replaying.py
    sed -i 's/result = testdir.runpytest(, "-p no:pretty")/result = testdir.runpytest("-p no:pretty")/' tests/test_blocking_network.py
    sed -i 's/result = testdir.runpytest(, "-p no:pretty")/result = testdir.runpytest("-p no:pretty")/' tests/test_plugin.py
    sed -i 's/result = testdir.runpytest(, "-p no:pretty")/result = testdir.runpytest("-p no:pretty")/' tests/test_recording.py
    sed -i 's/result = testdir.runpytest(, "-p no:pretty")/result = testdir.runpytest("-p no:pretty")/' tests/test_replaying.py
}

This make sure that pretty plugin is disbaled for the tests. Note that adding this function won't affect the tests if pretty plugin isn't installed so you can use it in every environment. If you want, try to edit the PKGBUILD file and test it in clean chroot.

gesh commented on 2025-02-23 17:56 (UTC)

https://wiki.archlinux.org/title/DeveloperWiki:Building_in_a_clean_chroot

tl;dr: install devtools, build using https://man.archlinux.org/man/pkgctl-build.1 (which sets up an isolated installation of Arch with just enough packages installed to build the package. I'm asking for this because it enables distinguishing between the PKGBUILD accidentally picking up a problem in your local configuration and the PKGBUILD not accounting for a legitimate difference of situations between you and me (eg, slow networks))

1 2 Next › Last »