search

hynek / build-and-inspect-python-package

Build and Inspect Python Packages in GitHub Actions
MIT License
181 stars 13 forks source link

Adds output that reflects a package's supported Python interpreters #80

Closed funkyfuture closed 8 months ago

funkyfuture commented 11 months ago

i think that addresses proposal #43 by @RonnyPfannschmidt that i liked.

let me know what you think should still be addressed.

funkyfuture commented 11 months ago

frohes neues! as your requirements are different than mine, i'm closing this.

hynek commented 11 months ago

frohes neues! as your requirements are different than mine, i'm closing this.

Honestly, I don't think they are.

There seems to be two things at play that sounds the same but aren't:

  1. The explicit enumeration of supported Python versions.
  2. requires-python providing packaging metadata

To me, it would make the most sense to use 1. to drive the CI and – and this doesn't have to be the same PR/step – checking if 1 and 2 are contradicting each other.

Since it's possible to define quite intricate versions in 2, I'm not even sure how realistic that is. I remember e.g. most asyncio packages requiring a later 3.5 minor release due to asyncio bugs.

funkyfuture commented 11 months ago

Honestly, I don't think they are.

honestly, i'm unsure whether i followed correctly until now.

There seems to be two things at play that sounds the same but aren't:

my impression is that the difference was clear all the time.

The explicit enumeration of supported Python versions.

i assume that you mean the respective trove classifiers with that?

To me, it would make the most sense to use 1. to drive the CI

i agree, because I do assume that all packages are supposed to be built and shipped with complete and correct metadata. (otherwise i consider it a bug that requires a patch release.)

checking if 1 and 2 are contradicting each other.

here i attempted to express that this a valid (even important) concern, but also that this proposal here isn't trying to solve that. it should be part of a metadata validation unit.

Since it's possible to define quite intricate versions in 2, I'm not even sure how realistic that is.

my consideration still is that it isn't worth the effort, particularly weighed against the previous argument.

if the above reflects a consensus, feel free to re-open this pr.

hynek commented 11 months ago

Currently, the only consensus that is needed is mine. We can work on this and merge it and let #43 open for further thinking/working on problem 2.

RonnyPfannschmidt commented 8 months ago

As project fmt fixes the python version list, I consider it a good enough source