mechanism for "auditwheel repair" to add a local version identifier?

[sbidoul]

Hi,

Running auditwheel repair may generate subtly different versions of the wheel, depending on the exact version of so libraries being included.

When looking at the wheel or otherwise running pip freeze there is no externally visible difference though.

I was wondering if it would make sense to have auditwheel repair accept a new optional "local version identifier" [1] argument that would be appended to the repaired wheel version.

This would enable user to encode some information about the embedded dependencies in the repaired version.

[1] https://www.python.org/dev/peps/pep-0440/#local-version-identifiers

[njsmith]

Note that local versions aren't allowed on PyPI -- it doesn't rule this out, but does mean that it'd only be useful in somewhat limited circumstances for local/private builds.

Another thing to consider looking at is the rarely-used "build tag" that wheel files support: https://www.python.org/dev/peps/pep-0427/#file-name-convention

What's your use case? Do you have multiple wheels that vendor different library versions that you need to keep track of? There are lots of ways that two versions of "the same wheel" can differ, well before auditwheel arrives on the scene -- using different compiler versions, different compiler options (optimized vs. debug), stripped binaries or not, different build-time configuration...

[sbidoul]

My use case is indeed local/private builds. For instance I'm looking for a mechanism to express that my private build of some wheel contains a specific version of libssl.so to know when I need to upgrade my frozen requirements.txt.

[sbidoul]

I've had a look at build tags. AFAIU it will not work for my use case because they are lost after install and do not come out in a pip freeze.

[ogrisel]

I am fine with adding an option to append a local version identifier. @sbidoul do you want to submit a PR?

[sbidoul]

@ogrisel I can give it a try.

I was wondering if there is are documented APIs to manipulate the version (I could not find it so far), or if the metadata files have to be manipulated "by hand".

[njsmith]

None of auditwheels APIs are documented :-). And I doubt there are any internal APIs for specifically this, because it isn't something that auditwheel needed before. But you could make one and then use it.

…

On Jan 3, 2017 8:43 AM, "Stéphane Bidoul (ACSONE)" ***@***.***> wrote: @ogrisel <https://github.com/ogrisel> I can give it a try. I was wondering if there is are documented APIs to manipulate the version (I could not find it so far), or if the metadata files have to be manipulated "by hand". — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAlOaPslJzOU6fIFP9tzF-2YN0-qm5u2ks5rOnqagaJpZM4KfqPW> .

[anntzer]

FWIW if auditwheel was updated to support the most recent version of wheel (but see #102), this would not need to be implemented on auditwheel's side, but would just be a matter of wheel unpack && wheel pack ... --build-number=....

[sbidoul]

@anntzer Support for build number in wheel pack is interesting. Yet I think this build number is not what I want. See my comment above.

[lkollar]

It would be nice if auditwheel could do this, but given that adding/changing local version identifiers needs to be done "manually" in a bunch of metadata files, we either need a tool or library we can use for this, or recommend an external tool for this. I'm not aware of any such tool, but opened pypa/wheel#570 in wheel as a feature request.