Idea: Arch 32/64 shortcut

[henryiii]

When looking at the build matrix here:

https://github.com/deepcharles/ruptures/blob/404957563c0391f073200899b9b041caa9277cc6/.github/workflows/upload-to-pypi.yml#L40-L80

It seems we could have shortcut values for ARCHS, "32" and "64", that would select 32 bit and 64 bit native architectures. So on 64 bit Windows or Linux, you could select 32 or 64. On macOS, you could only select 64, 32 would be empty (so an error after #545 unless --allow-empty was passed) or we could just make it an error. Same thing for 64 on 32bit OS's. On alternate archs, these remain the "native" on that arch 32/64 values.

I believe @mayeut wanted something like this too? Don't have the issue reference handy for it.

This would take a lot of pressure off the build selector. ARCHS, like BUILD/SKIP, already helps define the build process.

Old version

matrix:
  os: [ubuntu-latest, windows-latest, macos-latest]
  bitness: [32, 64]
  python: [36, 37, 38, 39]
  include:
    # Run 32 and 64 bits version in parallel for Linux and Windows
    - os: windows-latest
      bitness: 64
      platform_id: win_amd64
    - os: windows-latest
      bitness: 32
      platform_id: win32
    - os: ubuntu-latest
      bitness: 64
      platform_id: manylinux_x86_64
    - os: ubuntu-latest
      bitness: 32
      platform_id: manylinux_i686
    - os: macos-latest
      bitness: 64
      platform_id: macosx_x86_64
  exclude:
    - os: macos-latest
      bitness: 32
    - os: windows-latest
      python: 39
steps:
- uses: actions/checkout@v2
  with:
    fetch-depth: 0
- uses: actions/setup-python@v2
  name: Install Python
  with:
    python-version: '3.8'
- name: Install cibuildwheel
  run: |
    python -m pip install --upgrade pip
    python -m pip install cibuildwheel
- name: Build wheels
  env:
    CIBW_BUILD: cp${{ matrix.python }}-${{ matrix.platform_id }}
    run: python -m cibuildwheel --output-dir wheelhouse

New version

matrix:
  os: [ubuntu-latest, windows-latest, macos-latest]
  bitness: [32, 64]
  python: [36, 37, 38, 39]
  exclude:
    - os: macos-latest
      bitness: 32
    - os: windows-latest
      python: 39
steps:
- uses: actions/checkout@v2
  with:
    fetch-depth: 0
- name: Build wheels
  env:
    CIBW_BUILD: cp${{ matrix.python }}-*
  run: pipx run cibuildwheel==1.80 --output-dir wheelhouse --archs ${{ matrix.bitness }}

Thoughts? Hopefully @deepcharles doesn't mind me using his yaml as an example. :) Also used pipx for the "new" version, because why not, it's preinstalled. :)

[henryiii]

I didn't know you could do a partial exclude like that, by the way, nice. :)

[deepcharles]

all credit goes to @oboulant on that one

[YannickJadoul]

Maybe native64/native32, then? Just 32 or 64 seems a bit vague.
But then we have the weird issue that 32 isn't considered native on a 64-bit version of Linux, for example?

[henryiii]

I don't think --archs 32 or CIBW_ARCHS: "32" is at all vague when you are reading a config. Though I thought about suggesting native32 or native_32, something like that. I guess we could do auto32, to indicate that it's the same as auto but only the 32 bit part, but I think just 32 is fine. Though auto32/auto64 doesn't look that bad...

[henryiii]

32bit/64bit, possibly?

32/64 is my favorite, with auto32/auto64 a very close second.

[YannickJadoul]

Yeah, I'm not a huge fan of 32/64 just by itself. That could seem like it's going to build all 32-bit or 64-bit architectures. To be pedantic, aarch64 is also 64-bit (even though, yeah, it wouldn't make sense that it would be included in a convenience option 64, I agree). auto-64/auto64 (I might prefer the former one, but I'm not going to whine about single dash) does make a link with auto, I think :-)

[joerick]

This does seem like a convenient feature. The semantics do worry me a little though, as we have to consider if auto64 matches arm64 on mac. And if it matches aarch64 on Linux. To reduce ambiguity, it seems like either it's intel64, or it's native64.

[henryiii]

auto64 matches the current auto, it is the 64 bit architecture on whatever machine you are on, while auto is the native architecture of the machine you are on + the 32 bit version of the arch of the machine you are on, if it exists. Though fine with native64 too.

[henryiii]

So:

Machine	native	auto	auto64/native64	auto32/native32
Win 64	AMD64	x86 , AMD64	AMD64	x86
Win 32	x86	x86	{}	x86
Linux 64	x86_64	x86_64, i686	x86_64	i686
Linux 32	i686	i686	{}	i686
macOS Intel	x86_64	x86_64	x86_64	{}
macOS AS	arm64	arm64	arm64	{}
Linux ARM64	arm64	arm64	arm64	{}

[henryiii]

I'm 50/50 on the names. "native" always returns one value, like native, though it's not always the "native" arch. Auto never emulates, so I wouldn't auto64 to suddenly emulate. "auto" will always contain "auto32" and/or "auto64".

[YannickJadoul]

This does seem like a convenient feature. The semantics do worry me a little though, as we have to consider if auto64 matches arm64 on mac. And if it matches aarch64 on Linux. To reduce ambiguity, it seems like either it's intel64, or it's native64.

Shouldn't that be linked to whether auto matches arm64 on mac?

I like @henryiii's table and I would like native64/native32 better, but how do we deal with that line of Linux 64? native means x86_64, but native32 does suddenly include i686?
That's a bit tricky, to me; it seems like it's auto, but filtered on architecture, no? So that's why auto32/auto64 makes the most sense from my perspective. (I would have preferred to call the auto column native, before, but since we didn't go for that, I think we should stick to auto.)

[henryiii]

Same issue for Windows.

I don't think we've decided exactly what returns for auto on AS; it probably should not return all of x86_64, universal2, and arm64; I think from memory there's a good chance it will return {x86_64, universal2}. So that means if we name it native64, then it will likely return {x86_64}, and if we name it auto64, it likely will return {x86_64, universal2}.

[henryiii]

I think the more useful thing would be to have it match only one arch on Apple, as someone splitting builds by arch probably doesn't want to match two Apple ones. That would make it seem native64 is the better name. You do have the oddity that native32 does not return the same thing as native, but then at least native* always returns a single arch only, which from a practical standpoint is likely what someone not using auto/all would want. I think.

(Assuming auto does match more than one on Apple here, argument invalid otherwise)

[oboulant]

Sorry to interfere, thanks @deepcharles for citing me ! To be perfectly transparent, I found this useful exclude feature on sklearn repo
This lead me to this nice read on what is possible to be with strategy.matrix