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

Builds on prerelease Pythons frequently fail if they depend on lxml #161

Closed
jaraco opened this issue Feb 23, 2025 · 0 comments
Closed

Builds on prerelease Pythons frequently fail if they depend on lxml #161

jaraco opened this issue Feb 23, 2025 · 0 comments

Comments

@jaraco
Copy link
Owner

jaraco commented Feb 23, 2025

When adding a prerelease Python to the matrix, which is something that's continuously the case because a newer Python emerges when the old version becomes stable, any project that depends on lxml will fail because lxml hasn't yet released binaries for that version (and probably won't until around the time that version becomes stable).

As a workaround, I've been applying continue-on-error for that version of Python:

continue-on-error: ${{ matrix.python == '3.14' }}

And while that sort-of works, it has a few downsides:

  • The tests are still summarized as "failed" and show with the red x for the commit.
  • There's no easy way to tell from the UI that these tests are (sometimes) expected to fail.
  • These failures can be distracting and confuse investigation of real issues.
  • The failures mask real failures on that version of Python, meaning they won't be discovered until the version becomes stable.

In that issue, I learned that it may be straightforward to unblock lxml (and maybe other popular compiled-from-source dependencies).

      # Install required dependencies for building lxml
      - name: Install libxml2 and libxslt development packages
        if: matrix.python == '3.14' && matrix.platform == 'ubuntu-latest'
        run: |
          sudo apt-get update
          sudo apt-get install -y libxml2-dev libxslt-dev

Let's apply that and any other build-time dependencies in the skeleton to reduce the instances of failures due to missing build-time dependencies.

@jaraco jaraco closed this as completed in 75ce9ab Feb 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant