Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build, test: upgrade to vcrpy>=5 & refresh broken cassettes #2519

Merged
merged 1 commit into from
Oct 30, 2023

Commits on Oct 30, 2023

  1. build, test: upgrade to vcrpy>=5 & refresh broken cassettes

    This is *probably* the ideal solution to my issues with certain VCR
    cassettes failing locally, since we were on vcrpy 2.x for quite a long
    time. Skipping two whole major versions probably isn't ideal, but I like
    this solution because:
    
    * No more pinning urllib3 at runtime to make a dev requirement happy
    * No more snarky incompatibility warning from pip that types-requests
      wants urllib3 2.x but we have 1.x (seen in CI logs)
    * No more weird BrotliDecoderDecompressStream exceptions in my local
      environment (which didn't happen in CI)
    
    Note that this commit only updates half a dozen YAML cassettes for two
    plugins whose tests *failed* after upgrading vcrpy. Working cassettes
    have been left untouched.
    
    vcrpy 5 is currently installed from a fork that removes the upstream
    version cap on urllib3<2 for Python < 3.10, as it seems cassettes are
    often incompatible across major urllib3 versions. (Cassettes that would
    work when tests ran under urllib3 1.x raised exceptions under urllib3
    2.x, and vice versa.)
    
    Upstream, the vcrpy maintainers have been totally silent since I opened
    a pull request suggesting the removal of this version cap. After two
    weeks without any acknowledgement whatsoever, I chose to create a fork
    within Sopel's GitHub organization specifically for use with our CI and
    dev-environment setup.
    
    This should be more or less fine, since only CI and maintainers are
    likely to bother installing the dev-requirements. Packaged releases
    don't include them, so we can move pretty quickly to get current again
    whenever the vcrpy maintainers accept the change (or if they do).
    
    The "internal" fork also guards against deleting my personal fork. (When
    a patch I submitted is merged, I habitually delete my fork if I don't
    foresee making further contributions to that project.)
    dgw committed Oct 30, 2023
    Configuration menu
    Copy the full SHA
    3288fe7 View commit details
    Browse the repository at this point in the history