Open Stack

Trinh Nguyen <dangtrinhnt at gmail.com> writes:

> Thank Jeremy, Doug for explaining.
>
> On Fri, Oct 5, 2018 at 6:54 AM Doug Hellmann <doug at doughellmann.com> wrote:
>
>> Jeremy Stanley <fungi at yuggoth.org> writes:
>>
>> > On 2018-10-04 23:11:22 +0900 (+0900), Trinh Nguyen wrote:
>> > [...]
>> >> Please avoid adding universal wheels to the project setup.cfg.
>> > [...]
>> >
>> > Why would you avoid also adding it to the setup.cfg? The change you
>> > cited is merely to be able to continue building universal wheels for
>> > projects while the setup.cfg files are corrected over time, to
>> > reduce the urgency of doing so. Wheel building happens in more
>> > places than just our CI system, so only fixing it in CI is not a
>> > good long-term strategy.
>>
>> I abandoned a couple of dozen patches submitted today by someone who was
>> not coordinating with the goal champions with a message that said those
>> patches were not needed because I didn't want folks to be dealing with
>> this right now.
>>
>> Teams who want to update their setup.cfg can do so, but my intent is to
>> ensure it is not required in order to produce releases with the
>> automation in the short term.

I thought about this some more last night, looking for reasons not to
update all of the setup.cfg files. If this zuul migration project has
shown anything, it's that we need to continue to be creative with
finding ways to avoid touching every branch of every repository when we
have build system changes to make. I support decentralizing the job
management, but I think this is a case where we can avoid doing a bunch
of work, and so we should.

We've been saying we want to update the setup.cfg files to include the
setting to cause a universal wheel to build because we want the local
developer experience when building wheels to be the same as what we get
from the CI system when we publish packages. I don't think that's a real
requirement, though.

The default behavior of bdist_wheel is to create a version-specific
wheel, suitable for use with the version of python used to build it.
The universal flag makes a wheel file that can be used under either
python2 or python3.  Perhaps surprisingly, the contents of a universal
wheel are *exactly* the same as the contents of a version-specific
wheel. Literally the *only* difference is the filename, which includes
both versions so that pip will choose the universal file if no
version-specific file exists.

Therefore, for our CI system, we want to publish universal wheels to
PyPI because they are more usable to consumers installing from there
(including the CI system).

On the other hand, for local builds, there's no particular reason to
prefer a universal wheel over the version-specific format. If someone is
building their own wheels for internal consumption, they can easily
choose to keep the version-specific packages, or add the --universal
flag like we're doing in the CI job.

So, I think this all means we can leave the setup.cfg files as they are
and not worry about updating the wheel format flag.

Doug