ci: publish wheels to testpypi

[retr0h]

Pushes binaries to testpypi on merge.

Fixes: #127

[0xDEC0DE]

It would be wise to double-check that the result files here are still installable, calling the package go-gilt seemed to piss it off; this might do the same

[retr0h]

Yeah, I wont merge any of this without you verifying my hacks

[retr0h]

@0xDEC0DE any ideas?
https://github.com/retr0h/gilt/actions/runs/7661817890/job/20881911777

Possibly name the wheels "manylinux_2_17_{arch}.manylinux2014_{arch}.musllinux_1_1_{arch}"

see: https://github.com/Bing-su/pip-binary-factory/blob/main/lazygit/build_wheel.py#L37C1-L38C1

[0xDEC0DE]

@0xDEC0DE any ideas? https://github.com/retr0h/gilt/actions/runs/7661817890/job/20881911777

Possibly name the wheels "manylinux_2_17_{arch}.manylinux2014_{arch}.musllinux_1_1_{arch}"

see: https://github.com/Bing-su/pip-binary-factory/blob/main/lazygit/build_wheel.py#L37C1-L38C1

You can't mix manylinux and musllinux in tags, they'd need to be separate packages. On Intel, there's the common linux platform, I was hoping ARM had the same. Guess not.

[0xDEC0DE]

Although that change you linked seems to do it, so maybe... The docs I read seemed fairly confident it was a no-no, though.

[0xDEC0DE]

Pretty sure you want Version and not PreviousTag. Leading v is a bit of a no-no...

[0xDEC0DE]

ERROR HTTPError: 400 Bad Request from https://test.pypi.org/legacy/
Binary wheel 'python_gilt-2.0.4.dev-py3-none-linux_i686.whl' has an
unsupported platform tag 'linux_i686'.

Damn it, I thought I verified that would work!

angrily downloads a 32-bit Debian 12 VM

[0xDEC0DE]

root@debian12:~# pip debug --verbose 2>/dev/null | grep py3-none-linux_i686
  py3-none-linux_i686
root@debian12:~# uname -a
Linux debian12.localdomain 6.1.0-16-686-pae #1 SMP PREEMPT_DYNAMIC Debian 6.1.67-1 (2023-12-12) i686 GNU/Linux

What — and I cannot stress this part enough — the fuck

[0xDEC0DE]

Aha, it's banned: https://peps.python.org/pep-0513

[0xDEC0DE]

OK:

root@002498cdfe12:/# lsb_release -d 2> /dev/null
Description:	Ubuntu 22.04.3 LTS
root@002498cdfe12:/# arch
x86_64
root@002498cdfe12:/# pip debug --verbose 2>/dev/null | grep py3-none-manylinux1
  py3-none-manylinux1_x86_64

root@debian12:~# lsb_release -d 2> /dev/null
Description:	Debian GNU/Linux 12 (bookworm)
root@debian12:~# arch
i686
root@debian12:~# pip debug --verbose 2>/dev/null | grep py3-none-manylinux1
  py3-none-manylinux1_i686

I cannot find an ARM64 VM that will boot under VirtualBox, but I'll keep trying.

[0xDEC0DE]

Damn. Alpine strikes again:

(venv) bash-5.1# pip debug --verbose 2>/dev/null | grep py3-none-
  py3-none-musllinux_1_2_x86_64
  py3-none-musllinux_1_1_x86_64
  py3-none-musllinux_1_0_x86_64
  py3-none-linux_x86_64
  py3-none-any

[retr0h]

I cannot find an ARM64 VM that will boot under VirtualBox, but I'll keep trying.

We can skip ARM for the moment and solve that after ?

[0xDEC0DE]

We can skip ARM for the moment and solve that after ?

This whole thing is becoming more trouble than it's worth...

manylinux1_aarch64 is likely correct, though, so it's likely safe to skip, until we have proof it won't work.

Your choices at this point are:

• Generate two identical wheels for musllinux_1_0 and manylinux1, whose only difference is the platform tag in the wheel metadata
• Generate a wheel with two Tag: attributes in the wheel metadata for Linux, and a wonky py3-none-manylinux1_musllinux_1_0_ filename

Each is horrible in its own unique way, but I suspect a lower total file count is the winner here.

[retr0h]

Each is horrible in its own unique way, but I suspect a lower total file count is the winner here.

I have a couple Ideas I'm going to toy around with, and each idea is worse than the other :)

[retr0h]

I was able to upload two test packages to test pypi.

• python_gilt-2.0.4.dev-py3-none-macosx_10_7_x86_64.whl
• python_gilt-2.0.4.dev-py3-none-manylinux2014_x86_64.manylinux_2_17_x86_64.musllinux_1_1_x86_64.whl

This may be incorrect, or can be improved, however, I am going to close this PR, as dev releases seem like too much trouble. I'm going to move the changes over to #129 for further review/punishment.