New release?

[bgermann]

When will there be a new release based on #79?

[rougier]

We can do it in a few hours indeed. Just need to think about the version number. Because of the big change, maybe we can jump to 2.0 or try to track freetype version number.

@madig @anthrotype @HinTak Any recommendation/comment on this?

[anthrotype]

i'm not sure it's a good idea to use freetype's own version number. It's true we always want to bump the wrapper's version whenever the wrapped library (or libraries) is updated, like in this case. But we may well have bugfixes or new features added to the wrapper which don't entail updating the embedded libs' versions. You could in theory use post releases for that (e.g. 2.9.0.post1, 2.9.0.post2, etc.) but you would then only have a single incremental number to distinguish among different post-releases, so no more semver.org distinction between major.minor.patch.
I'd recommend keeping the two version strings (the python wrapper and the bundled freetype and harfbuzz libraries) separate from each other.

[rougier]

I get your point. We still need a version number that convey (more or less) the idea of the big change that happened (while the API remains the same). 1.5 maybe?

[anthrotype]

i'm ok with 2.0.0

[anthrotype]

while the API remains the same

in that case, semver-strictly speaking, 1.3.0 would be the correct number. But you're free to chose what you prefer. I was just commenting on the suggestion to use the same version as the FreeType library.

[madig]

I suppose you can track FreeType and keep your own version number, i.e. if FT introduces a backwards compatible change in the API via a minor version, you can increment your minor version as well. Same with major and patch versions. Incremented Harfbuzz versions can probably be tracked the same way? Or just as a patch number since it isn't directly exposed.

[rougier]

Let's say 2.0.0 then.

[bgermann]

Are there any news on this?

[rougier]

Totally forgot... Will do today, sorry for the delay.

[rougier]

Done.

[rougier]

@madig @HinTak : I've invited you as collaborators (push access) on the repo. Since I'm not too much reactive, this might help.

[madig]

https://travis-ci.org/rougier/freetype-py/jobs/397335218

"PyPI upload failed." 😢

Uploading distributions to https://upload.pypi.org/legacy/
Uploading freetype_py-2.0-py3-none-any.whl
100%|███████████████████████████████████████| 76.7k/76.7k [00:00<00:00, 155kB/s]
HTTPError: 400 Client Error: File already exists. See https://pypi.org/help/#file-name-reuse for url: https://upload.pypi.org/legacy/

[madig]

https://travis-ci.org/rougier/freetype-py/jobs/397335217

This job seems to fail to bundle FT and thus uploads freetype_py-2.0-py3-none-any.whl, which then conflicts with the next job.

[madig]

Restarting the Travis job just to check.

[rougier]

It seems to have just passed....

[madig]

"Skipping a deployment with the pypi provider because this is not a tagged commit"

Ugh. I'd need to dig into this later... PyPI now has a partially updated file list: https://pypi.org/project/freetype-py/#files. The unbundled wheel should be a universal one, so it gets the py2-py3 tag 🤔

[bgermann]

The certificate on https://nipy.bic.berkeley.edu/ is expired.

[bgermann]

...which is fixed upstream. You should update the multibuild submodule.

[madig]

So... maybe I'll just tag "2.0.0" after I merged #90 so we can overwrite what's on PyPI.

[anthrotype]

you can't overwrite what's on PyPI. You can delete uploaded files, but to upload new ones you always need to bump the version, otherwise it fails. It's by design. You could keep the same version and use a PEP440 "post-release" specifier: e.g. "2.0.0.post1"
https://www.python.org/dev/peps/pep-0440/#post-releases

[madig]

Yes, but the current version is "2.0", so maybe "2.0.0" works? 😁

[anthrotype]

no. versions are normalized. 2.0 == 2.0.0

[madig]

Alright, universal, Linux and macOS wheels are online. Just the Window wheels don't deploy: https://ci.appveyor.com/project/rougier/freetype-py/build/job/plkg08phf91jct69 😠 Looks like some shell expansion issue.

[anthrotype]

try removing the hack that uses cmd to execute twine, and just call it directly in the powershell multiline command, like we do here:

https://github.com/google/brotli-wheels/blob/6e50083e11de7a2e0c183893ac82ee1b05e7b47d/appveyor.yml#L88-L97

powershell should expand the glob pattern

[anthrotype]

and maybe tag a .post2 release. I know, it's super frustrating, but once you get it right it pays off. Well, at least until something else breaks as Travis/Appveyor/multibuild/etc. change over time.

[anthrotype]

the cmd/twine hack required because twine used to log to stderr (which tripped powershell), but the latest prints to stdout so it works

[anthrotype]

pypa/twine#288

[anthrotype]

looking at https://pypi.org/project/freetype-py/2.0.0.post1/#files

I don't see the source distribution (either .tar.gz or .zip) uploaded. There should be one for platforms for which we don't have pre-built wheels, so they can build from source and depending on the env variable use the system library or build the embedded one.

Also, do we actually need to also upload to PyPI the wheel without the embedded DLL? ie. the one ending with tag -py2.py3-none-any.whl . I think it would be simpler/cleaner to have binary wheels only for the embedded-library variant, and a source distribution for when a platform isn't supported or when a user explicitly requests --no-binary

[madig]

Ah, thanks. Can't find any reference to deploy_script in https://www.appveyor.com/docs/build-configuration/#build-pipeline though... will keep on_success.

Oh yes, I forgot the sdist. Hm. One more matrix entry then or some fudging.

I'd keep Wheels for unbundled distribution because PyPA says so: https://packaging.python.org/guides/distributing-packages-using-setuptools/#wheels

[anthrotype]

just add a python setup.py sdist in this line:

freetype-py/.travis.yml

Line 69 in e1de05b

- if [ -n "$TRAVIS_TAG" ]; then mkdir -p dist; cp wheelhouse/*.whl dist; fi

I'd keep Wheels for unbundled distribution because PyPA says so

but then, is not clear which wheel (with bundled lib, or unbundled universal) is going to take precendence and under which circumstances. I presume, if a platform supports one of the available platform-specific wheels, those will be automatically selected, and the one with 'none' ABI flag will only be used for non-supported platforms, with no means from a pip command line to select which? I think this is not very good. Better to use wheels only for true binary distributions, and the sdist for pure-python-without-bunded-native-lib sources.

[anthrotype]

note that when you do pip install something and a compatible wheel is not there, pip will build one from the sdist, (add it to its cache) and install it.
On the other hand, if the user does pip install --no-binary=:all: something and only wheels are present, but not sdist package, then it will fail.

[madig]

just add a python setup.py sdist in this line:

Wouldn't that build 3 sdists and make deploy fail? 🤔

but then, is not clear which wheel (with bundled lib, or unbundled universal) is going to take precendence and under which circumstances.

https://www.python.org/dev/peps/pep-0425/#id1 recommends that installers go from specific to pure wheels. Let's just hope that pip honors this 😀

[madig]

Well that didn't work.

[anthrotype]

it will work with dist/*.whl now.

the sdist package wasn't uploaded though:
https://pypi.org/project/freetype-py/2.0.0.post2/#files

this line:

freetype-py/.travis.yml

Line 63 in 93751dc

- if [ -z $"FREETYPEPY_BUNDLE_FT" && -n "$TRAVIS_TAG" ]; then python setup.py sdist; fi

is not valid bash:

https://travis-ci.org/rougier/freetype-py/jobs/399574506#L513

also you want to build the sdist package only once, not for every build. Build it with python 3.6 only, by setting some env variable (e.g. BUILD_SDIST=true) in the Travis build matrix for the python3.6 job only, like we do in fonttools

https://github.com/fonttools/fonttools/blob/8d7774a3e81df1afc6dedb1272e43c7c3aea100e/.travis.yml#L25

[anthrotype]

and then of course you would run python setup.py sdist only when BUILD_SDIST is true

[madig]

https://ci.appveyor.com/project/rougier/freetype-py/build/job/klm4xknx13vox2oc

... groan. So either the whl is not in dist or the shell expansion doesn't work here.

[anthrotype]

It is in dist, otherwise Appveyor could not upload the 'artifacts" here:

https://ci.appveyor.com/project/rougier/freetype-py/build/1.0.95/job/klm4xknx13vox2oc/artifacts

given this:

freetype-py/appveyor.yml

Line 68 in 89496f2

- path: dist\*.whl

don't add more hacks on top of hacks

[anthrotype]

this ought to work:
https://github.com/joerick/cibuildwheel-autopypi-example/blob/d65184613a7ff0abaa988f9cf50c735729008cb6/appveyor.yml#L8-L14

[madig]

Hm. PowerShell doesn't do expansion by itself, the cmdlet has to do it...

> Write-Host .\dist\*
.\dist\*

> Write-Host (ls .\dist\*)
C:\UsersLocal\nikolaus.waxweiler\Development\freetype-py\dist\freetype-py-2.0.0.post2.dev1+gc0b5472.d20180703.tar.gz

[anthrotype]

use the snippet I linked to above. it doesn't use powershell, but runs inside cmd.exe like the rest of the appveyor commands

if it works for cibuildwheel-autopypi-example, it will work for us too!

[madig]

Let's hope.

[anthrotype]

it worked!
https://pypi.org/project/freetype-py/2.0.0.post6/#files

🎉

[bgermann]

Thanks!

[madig]

Finally!

…

On Tue, 3 Jul 2018, 18:51 bgermann, ***@***.***> wrote: Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#88 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXPndEjIvKRiN7jdmPkRn9sJk61Icpeks5uC68NgaJpZM4Uia_S> .