#why

1 messages · Page 1 of 1 (latest)

sterile knot
#

because of this exact situation, I think this adds complexity and I don't see many use cases

#

I think changes should only be reflected in the project version

hoary tangle
#

The use case is "I need to rebuild the wheel due to problems in the built artifact", revving the version number can be a heavy operation

heady sapphire
#

This is technically what post releases are for

sterile knot
#

I mean for other software that means a patch release

hoary tangle
#

eh

#

not true

#

well not universally true

#

it's not like we invented the concept of a build tag

heady sapphire
#

post release is for metadata change with no code change
Build tag is for no code change or metadata change

#

Patch release is for a code level bugfix

hoary tangle
#

(I would pick post releases as a feature to remove long before build tags tbh)

sterile knot
#

what is it changing if not code? I'm asking in the case of Pillow

full meadow
#

post releases are free though, build tags require special handling

sterile knot
#

the compiled extensions?

hoary tangle
#

yes typically

hoary tangle
sterile knot
#

If something that the end user is running is changed that is different code, it doesn't matter if your source is different to me nor for security purposes

hoary tangle
#

Certainly one could use version numbers to implement build tags, but the process of a release isn't always lightweight

#

some people have to build like a dozen or more artifacts, sometimes quite large artifacts, and it's kind of unsatisifying to say they need to redo all that churn because one random platform had a problem in the build enviornment

full meadow
hoary tangle
#

I don't believe build tags complicate the resolution process

full meadow
#

the artifact selection process then 😛

sterile knot
#

until last week I didn't know they existed

hoary tangle
#

They're documented in the spec? Did you reverse engineer hatch's wheel support?

#

Anyways, I don't think there's any reason to talk past each other here 🙂 I was curious why you'd want to remove them, and you gave that answer, thanks!

sterile knot
#

I think I must have either completely missed that part or assumed it was a legacy thing that no one actually uses

hot bolt
hot bolt
sleek spade
#

Coming here from an identical conversation about build numbers. I'm also of the opinion that they should be avoided in favor of post-releases because they aren't a part of the version component.

#

Because they're not a part of the version it means that there's no equivalent for tooling outside the ecosystem to be able to annotate what it means to have a "wheel build number". For example if rebuilding a wheel fixes a security vuln how is that supposed to be represented in a CVE/OSV?

sleek spade
#

They have an effect on resolution but not a part of the package version.

full meadow
#

post releases are part of PEP 440

sleek spade
#

oh sorry I thought you were referencing build numbers, my bad ignore me

hoary tangle
#

well

#

build numbers are intended to let you release a new build without having to rebuild every other artifact

#

post numbers don't satisify that constraint

sterile knot
#

question: do other build/packaging ecosystems have that concept or are binaries usually built anew for every target if there is an issue?

hot bolt
#

hmm, well homebrew just updated my git from git 2.41.0 -> 2.41.0_1, but it's still 2.41.0, the _1 must be a homebrew packaging update

$ git --version
git version 2.41.0
hoary tangle
#

I'm pretty sure I've seen other packaging ecosystems have that concept, though I've have to look to figure out which

hot bolt
hoary tangle
#

or they solve the problem in another way

#

e.g. they're useful in Python because:

  • We have binary artifacts, ecosystems without binary artifacts wouldn't need them.
  • We treat our artifacts as immutable, ecosystems that don't would just replace the existing artifact.
  • It's considered normal and best practices to pin to a specific version in a deployment, ecosystems that don't can just release a new version that only has a limited subset of binary targets.
  • When a binary version isn't available, it's typical to fall back to installing from source, which is often undesireable, but systems that don't do that fall back don't have the same concern.

AFAIK most systems with binary artfacts have some method to let you do partial rebuilds, but == in Python makes many of the more common solutions unworkable

sleek spade
#

I think the main difference between Python and those other ecosystems (at least the ones I know of) they treat this extra post-build number as part of the version (both for installing and listing installed packages). Python not treating it as part of the version is part of the challenge.

hoary tangle
#

the ones that treat it as part of the version generally either don't have pinning in common use, or have entirely separate repos for different architectures, so there's no need for the version number to match between archs

sleek spade
#

That makes sense, but Python doesn't fit either of those categories. We want pinning and the same repo for different arch. There's also the "this only applies to wheels" caveat that makes it difficult to reference externally too.

#

To make my intentions clear, I am wondering if there's something that can be done wrt to security vulns and build numbers. Build numbers have the use-case of being able to rebuild wheels without rebuilding a whole release and that seems useful, but when a security issue is solved with that method I could forsee it causing confusion (ie CVE lists v1.0.1 as having the fix but you need v1.0.1-1 installed). I'm not sure long-term what the "solution" to that looks like, maybe it's guidance or something more?

hoary tangle
#

I would probably recommend not using build numbers for remediating security issues

#

you (purposely) can't put a build number in a version spec, so people have no way to depend on a not-insecure thing

#

In theory, in narrowly enough scoped vulnerabilities you could just rev the build number, but the same is true where you could also like, release a manylinux wheel with a newer (or older) manylinux tag or something

#

or using a different set of compressed tags

#

or whatever

#

none of those mechanisms are great ways to fix security vulns

#

So I guess I'd say buld number should be thought of as something that users should never care about, to fix bugs that only affect a subset of binary targets, and if your bug is something that users are going to care about ensuring they don't have (like with a sec vuln) then you should be using real version numbers

sleek spade
#

That's my thought was well, that build numbers should be invisible and not need to be referenced externally at all. Maybe there are other use-cases where we should avoid build numbers/new tags but security is the one that's top-of-mind for me. I want to put together some guidance on this and wanted to verify my thinking.

sleek spade
hoary tangle
#

Starting with a thread is probably the right next step