Upped version to 2.6.10

[waylan]

This version was released to force PyPI to point to the new docs location.
Closes #601. The old PyPI hosted docs can be deleted after this.

[waylan]

Arg! Apparently we can't upload to PyPI via HTTP anymore (only HTTPS). But that only works with newer Python versions, which I don't have installed on this machine (and can't easily update for reasons). I can't even get twine to work due to a InsecurePlatformWarning.

Guess the deployment to PyPI will need to wait to I have access to another machine (in a few hours). I understand PyPI's end goal, but their path to getting there is extremely frustrating and feels very user hostile.

[facelessuser]

I personally let Travis deploy when I cut a release. Makes it easier for me (until the next drastic change).

[waylan]

I also discovered that my (clever, I thought) solution for deploying the docs is faulty. See c-w/ghp-import#65. I hosed my local repo and had to do a hard reset. Then, after merging some upstream commits, the deploy failed as it was causing a merge conflict. Unless/until my request in c-w/ghp-import#65 is met, I need to script the deploy.

[facelessuser]

Unfortunately, I don't have much experience with deploying to group. I hadn't realized how much different it was.

[waylan]

I personally let Travis deploy when I cut a release. Makes it easier for me (until the next drastic change).

Deploying with Travis means dealing with deploy/auth keys. Until now, it was always easier to just run the command locally. But deploy keys won't work anyway. According to GitHub's docs, "Deploy keys aren't supported for Organization Pages." You have to "set up a machine user as a member of your organization". I don't even know if that is possible on Travis (and haven't looked into it) as you need to "run the ssh-keygen procedure on your server".

Of course, that doesn't apply to PyPI, but PyPi still requires an auth key, which I'd rather not have to deal with.

[facelessuser]

Ugh. What a headache.

[waylan]

See also my followup with MkDocs in this comment. If/when mkdocs/mkdocs#543 gets implemented, deploying to user/org pages should be easier than they are now.

[waylan]

Well, I pushed the release to PyPI, but I got this response:

running upload
Submitting dist/Markdown-2.6.10.zip to https://upload.pypi.org/legacy/
Server response (200): OK
Submitting dist/Markdown-2.6.10.tar.gz to https://upload.pypi.org/legacy/
Upload failed (400): Only one sdist may be uploaded per release.
error: Upload failed (400): Only one sdist may be uploaded per release.

The line I've been using for years in my makefile is:

python setup.py sdist --formats zip,gztar upload

It appears that the zip file uploaded and is now blocking the tar.gz file from uploading. So I guess 2.6.10 will have a zip file only.

[facelessuser]

That's weird. So if the base name is the same and the extension is different it rejects it? I guess the name is technically different for win, osx, linux, and with x86 etc.

What a mess.

[waylan]

I suppose it is all part of their push for wheels, which I'd use of we were using setuptools. But it seems ridiculous that you need non-standard-library libs to use the standard package manager's preferred defaults. In any event, I'm mostly posting things here to document them for future reference, not to complain.

[facelessuser]

Very interesting. I'm glad you are documenting this. The information will be useful for the future. Most of the time I don't know about these issues until I run into them (like what is happening here).

[jimporter]

I can't even get twine to work due to a InsecurePlatformWarning.

pip install 'urllib3[secure]' is how I solved this. You can just install it in a virtualenv (or whatever you like) and then happily use twine to upload to PyPI even on older Pythons; I've done it on 2.7.6 (I tend to use 2.7 as my dev env because it's easier to make sure I'm not accidentally breaking things for 2.7).