Skip to content

Package dependency guidelines #558

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

Open
RobPasMue opened this issue Feb 6, 2025 · 3 comments
Open

Package dependency guidelines #558

RobPasMue opened this issue Feb 6, 2025 · 3 comments

Comments

@RobPasMue
Copy link
Member

Coming from ansys/pyansys#842 (comment) we realized that this information is not published anywhere. We should clarify better how packages should handle dependencies for various purposes - just like @greschd outlined there.

@greschd
Copy link
Member

greschd commented Mar 13, 2025

TODOs:

  • CI / CD must use pinned dependencies. Provide examples using uv (with flit or hatch), poetry.
  • Create guidance about version range upper limits (only when absolutely necessary / known incompatibility exists)
  • Provide SBOM files on releases (only for shipped dependencies incl. extras, not for dev-only dependencies) this information will be outdated immediately, so does not provide any value
  • Provide setup examples for dependabot on the lockfile (with CVE alerts).
  • Add guidance on creating releases: when a CVE update requires modifying the dependency version range, a release should be created
  • Create an SBOM alongside the create-wheelhouse action
  • Create a security practice / timeline statement. Should this also include how to deal with archiving unsupported libraries of our own?

@da1910
Copy link
Contributor

da1910 commented Apr 17, 2025

Add guidance on creating releases: when a CVE update requires modifying the dependency version range, a release should be created

I cannot recall what we decided here in the end. If we are only releasing by tagging main as we go then this makes sense, if you have to update a version range to extend support to a new version with a fix this means a release so users can get a non-vulnerable version.

If we have multiple release branches, does this mean we intend to keep dependencies for all of these up to date? Can we even do that with dependabot?

@greschd
Copy link
Member

greschd commented Apr 17, 2025

If we have multiple release branches, does this mean we intend to keep dependencies for all of these up to date? Can we even do that with dependabot?

I think it's only feasible to do this on the main branch.

We did discuss that if the metapackage and / or downstream app developers cannot match non-vulnerable versions (using our release), they can provide another signal that a new release might be required.

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

3 participants