Source ZIP didn't get uploaded to PyPi for 0.13.0

[alerque]

Trying to update Arch Linux packaging, and the source ... isn't there yet. The release and a bunch of prebuilt wheels are, but not the source ZIP that was previously available on releases. It's possible to switch to Github sources, but the use of setuptools-scm makes that complicated and I would have to setup a patch to remove it and fill in the missing release info. The generated source dist is much easier to work with.

[justvanrossum]

It probably has to do with the new build system, but I have no clue about the deeper cause. @ebraminio or @anthrotype?

The GH release page offers the sources as zip and tar.gz, but that's perhaps what you mean, and isn't easy to use in your case? https://github.com/harfbuzz/uharfbuzz/releases/tag/v0.13.0

[alerque]

The GH release page offers zip/tar downloads that are the output of git archive. For Python projects that use setuptools_scm this is not enough to build a package from. You can clone the entire repo with history and build that way, but that's not ideal for stable versions packaged for distros. It's also possible to swap out setuptools_scm for setuptools with a patch and inject the necessary version data, but that's also a hassle. The Python build system when it generates the source distribution ZIP replaces a bunch of things in the source so that it can be built out of the box with no modification. I don't know what the command is off the top of my head but it should be a pretty simple option to get source builds back posted to PyPi releases.

[alerque]

A check of these docs suggest in Python land the name of the thing we're looking for here is a "Source Distribution". Note this is different than just an archive of the source (what GH gives) and different than a "Built Distribution".

It looks like you need to run python setup.py sdist and get that to PyPi. This was being done somehow before.

[justvanrossum]

It seems that travis is configured to do that:

uharfbuzz/.travis.yml

Lines 43 to 44 in 26bee8f

	$PYTHON setup.py sdist
	$PYTHON -m twine upload dist/*.zip

Not sure why that didn't happen, or what else could have changed.

[alerque]

From the Travis log:

Traceback (most recent call last):
  File "setup.py", line 8, in <module>
    from Cython.Build import cythonize
ImportError: No module named Cython.Build
InvalidDistribution: Cannot find file (or expand pattern): 'dist/*.zip'

It looks like you're not installing all the build time dependencies into the CI environment.

[alerque]

Also that pip install line needs to have setuptools_scm not setuptools I believe.

uharfbuzz/.travis.yml

Line 42 in 26bee8f

$PYTHON -m pip install $PIP_INSTALL_OPTIONS setuptools

[anthrotype]

The error message says that cython could not be imported, apparently we import it unconditionally in setup.py and the python setup.py sdist command is failing because of that. We need to make sure to also pip install cython before creating the sdist

[anthrotype]

setuptools_scm is automatically installed via setup_requires keyword in setup.py, you don't need to pip install it beforehand. Technically cython too could be added to setup_requires but given it is a native package (with extensions) and setup_requires traditionally uses setuptoools .egg distribution packages (instead of .whl wheels) it's not recommended to use for that

[alerque]

@justvanrossum Whatever we do to fix CI it isn't going to retroactively fix the last release. Can you manually build the source distribution for 0.13.0 and post it to PyPi so I can update distro packaging?

Edit: Given the Twine username being used in CI is yours @anthrotype maybe the above request should be directed at you.

[justvanrossum]

Right, I was just writing this: I'd prefer to get it fixed and do a 0.13.1 release: I personally don't have access to PyPI upload, so I can only do it indirectly through CI. Unless @anthrotype likes to do it.

[anthrotype]

Would you like me to build a sdist locally and upload to PyPI for 0.13? I could do that later.
Alternatively we can mark this current release as deprecated (there's a new feature on PyPI for that) and tag a new one

[alerque]

I don't really care—either way nets me a workable end result, but the former seems like less churn for anybody following the project closely that might have already updated their project(s).

[anthrotype]

I personally don't have access to PyPI upload

I just added your PyPI username ("just") as co-maintainer on the uharfbuzz PyPI account