[issue47016] Create a test verifying bundled pip and setuptools wheels

[Alex Waygood]

Change by Alex Waygood :


--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47016] Create a test verifying bundled pip and setuptools wheels

[Illia Volochii]

Change by Illia Volochii :


--
keywords: +patch
pull_requests: +29983
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31885

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47016] Create a test verifying bundled pip and setuptools wheels

[Illia Volochii]

Change by Illia Volochii :


--
nosy: +pablogsal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue47016] Create a test verifying bundled pip and setuptools wheels

[Illia Volochii]

New submission from Illia Volochii :

Bundled pip and setuptools wheels have to be verified manually at the moment 
when they are upgraded.
We can automate this by comparing their checksums to ones provided by 
Warehouse’s JSON API (e.g., https://pypi.org/pypi/pip/json.)

Since such a check requires network activity and not to slow down tests, 
creating a GitHub Actions workflow that runs only when the files are changed is 
a good option.

I suggested this in 
https://github.com/python/cpython/pull/30178#issuecomment-998765841 originally.

--
components: Library (Lib)
messages: 415193
nosy: illia-v
priority: normal
severity: normal
status: open
title: Create a test verifying bundled pip and setuptools wheels
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue47016>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

NumPy Python 3.10.0rc1 wheels.

[Charles R Harris]

Hi All,

There are now NumPy Python 3.10.0rc1 wheels available for 64 bit Linux on
Intel. You can install them from the nightly builds using "pip install -i
https://pypi.anaconda.org/scipy-wheels-nightly/simple numpy". Test away.

Cheers,

Charles Harris
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[issue42022] Allow ensurepip to work without bundled wheels

[Filipe Laíns]

Filipe Laíns  added the comment:

Closing as the new --with-wheel-pkg-dir option provides an alternative 
mechanism.

--
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ANN] PyYAML-5.4b1: Linux and Mac users, please test wheels!

[Matt Davis]

===
Announcing PyYAML-5.4b1
===

A beta release of PyYAML is now available:
https://github.com/yaml/pyyaml/releases/tag/5.4b1

This release contains a security fix for CVE-2020-14343. It removes the
python/module, python/object, and python/object/new tags from the
FullLoader.
YAML that uses these tags must be loaded by UnsafeLoader, or a custom loader
that has explicitly enabled them.

This beta release also adds Python wheels for manylinux1 (x86_64) and
MacOS (x86_64) with the libyaml extension included (built on libyaml 0.2.5).
We believe these wheels to be stable, but please take the opportunity to
test
against your local Linux and MacOS environments, and file any issues at
https://github.com/yaml/pyyaml/issues.

PyYAML 5.4 will be the last release to support Python 2.7.


Changes
===

* https://github.com/yaml/pyyaml/pull/407 -- build modernization, remove
distutils, fix metadata, build wheels, CI to GHA
* https://github.com/yaml/pyyaml/pull/472 -- fix for CVE-2020-14343, moves
arbitrary python tags to UnsafeLoader
* https://github.com/yaml/pyyaml/pull/441 -- fix memory leak in implicit
resolver setup
* https://github.com/yaml/pyyaml/pull/392 -- fix py2 copy support for
timezone objects
* https://github.com/yaml/pyyaml/pull/378 -- fix compatibility with Jython


Resources
=

PyYAML IRC Channel: #pyyaml on irc.freenode.net
PyYAML homepage: https://github.com/yaml/pyyaml
PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation
Source and binary installers: https://pypi.org/project/PyYAML/
GitHub repository: https://github.com/yaml/pyyaml/
Bug tracking: https://github.com/yaml/pyyaml/issues

YAML homepage: http://yaml.org/
YAML-core mailing list:
http://lists.sourceforge.net/lists/listinfo/yaml-core


About PyYAML


YAML is a data serialization format designed for human readability and
interaction with scripting languages. PyYAML is a YAML parser and emitter
for
Python.

PyYAML features a complete YAML 1.1 parser, Unicode support, pickle support,
capable extension API, and sensible error messages. PyYAML supports standard
YAML tags and provides Python-specific tags that allow to represent an
arbitrary Python object.

PyYAML is applicable for a broad range of tasks from complex configuration
files to object serialization and persistence.


Example
===

>>> import yaml

>>> yaml.full_load("""
... name: PyYAML
... description: YAML parser and emitter for Python
... homepage: https://github.com/yaml/pyyaml
... keywords: [YAML, serialization, configuration, persistence, pickle]
... """)
{'keywords': ['YAML', 'serialization', 'configuration', 'persistence',
'pickle'], 'homepage': 'https://github.com/yaml/pyyaml', 'description':
'YAML parser and emitter for Python', 'name': 'PyYAML'}

>>> print(yaml.dump(_))
name: PyYAML
homepage: https://github.com/yaml/pyyaml
description: YAML parser and emitter for Python
keywords: [YAML, serialization, configuration, persistence, pickle]


Maintainers
===

The following people are currently responsible for maintaining PyYAML:

* Ingy döt Net
* Matt Davis

and many thanks to all who have contribributed!
See: https://github.com/yaml/pyyaml/pulls


Copyright
=

Copyright (c) 2017-2020 Ingy döt Net 
Copyright (c) 2006-2016 Kirill Simonov 

The PyYAML module was written by Kirill Simonov .
It is currently maintained by the YAML and Python communities.

PyYAML is released under the MIT license.
See the file LICENSE for more details.
-- 
https://mail.python.org/mailman/listinfo/python-list

[ANN] PyYAML-5.4b1: Linux and Mac users, please test wheels!

[Matt Davis]

===
Announcing PyYAML-5.4b1
===

A beta release of PyYAML is now available:
https://github.com/yaml/pyyaml/releases/tag/5.4b1

This release contains a security fix for CVE-2020-14343. It removes the
python/module, python/object, and python/object/new tags from the
FullLoader.
YAML that uses these tags must be loaded by UnsafeLoader, or a custom loader
that has explicitly enabled them.

This beta release also adds Python wheels for manylinux1 (x86_64) and
MacOS (x86_64) with the libyaml extension included (built on libyaml 0.2.5).
We believe these wheels to be stable, but please take the opportunity to
test
against your local Linux and MacOS environments, and file any issues at
https://github.com/yaml/pyyaml/issues.

PyYAML 5.4 will be the last release to support Python 2.7.


Changes
===

* https://github.com/yaml/pyyaml/pull/407 -- build modernization, remove
distutils, fix metadata, build wheels, CI to GHA
* https://github.com/yaml/pyyaml/pull/472 -- fix for CVE-2020-14343, moves
arbitrary python tags to UnsafeLoader
* https://github.com/yaml/pyyaml/pull/441 -- fix memory leak in implicit
resolver setup
* https://github.com/yaml/pyyaml/pull/392 -- fix py2 copy support for
timezone objects
* https://github.com/yaml/pyyaml/pull/378 -- fix compatibility with Jython


Resources
=

PyYAML IRC Channel: #pyyaml on irc.freenode.net
PyYAML homepage: https://github.com/yaml/pyyaml
PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation
Source and binary installers: https://pypi.org/project/PyYAML/
GitHub repository: https://github.com/yaml/pyyaml/
Bug tracking: https://github.com/yaml/pyyaml/issues

YAML homepage: http://yaml.org/
YAML-core mailing list:
http://lists.sourceforge.net/lists/listinfo/yaml-core


About PyYAML


YAML is a data serialization format designed for human readability and
interaction with scripting languages. PyYAML is a YAML parser and emitter
for
Python.

PyYAML features a complete YAML 1.1 parser, Unicode support, pickle support,
capable extension API, and sensible error messages. PyYAML supports standard
YAML tags and provides Python-specific tags that allow to represent an
arbitrary Python object.

PyYAML is applicable for a broad range of tasks from complex configuration
files to object serialization and persistence.


Example
===

>>> import yaml

>>> yaml.full_load("""
... name: PyYAML
... description: YAML parser and emitter for Python
... homepage: https://github.com/yaml/pyyaml
... keywords: [YAML, serialization, configuration, persistence, pickle]
... """)
{'keywords': ['YAML', 'serialization', 'configuration', 'persistence',
'pickle'], 'homepage': 'https://github.com/yaml/pyyaml', 'description':
'YAML parser and emitter for Python', 'name': 'PyYAML'}

>>> print(yaml.dump(_))
name: PyYAML
homepage: https://github.com/yaml/pyyaml
description: YAML parser and emitter for Python
keywords: [YAML, serialization, configuration, persistence, pickle]


Maintainers
===

The following people are currently responsible for maintaining PyYAML:

* Ingy döt Net
* Matt Davis

and many thanks to all who have contribributed!
See: https://github.com/yaml/pyyaml/pulls


Copyright
=

Copyright (c) 2017-2020 Ingy döt Net 
Copyright (c) 2006-2016 Kirill Simonov 

The PyYAML module was written by Kirill Simonov .
It is currently maintained by the YAML and Python communities.

PyYAML is released under the MIT license.
See the file LICENSE for more details.
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[issue42022] Allow ensurepip to work without bundled wheels

[Filipe Laíns]

New submission from Filipe Laíns :

Some Linux distributions, such as Debian, have guidelines against shipping 
things like prebuilt wheels.

Taking Debian as an example, they remove the pip and setuptools wheels and 
consequently break ensurepip. This also has some implications in the venv 
module.

As a way to fix this, I would like to propose for ensurepip to install .pth 
files pointing to the pip and setuptools packages in purelib/platlib.

This behavior could either be switched on by a flag in the makefile or, maybe, 
if the wheels are not found.

Do you think this would be a reasonable approach?
Currently, we cannot rely on the ensurepip to work. Some projects that really 
need it are shipping a vendored version of the module.

--
components: Library (Lib)
messages: 378524
nosy: FFY00, dstufft, ncoghlan, p-ganssle, pradyunsg
priority: normal
severity: normal
status: open
title: Allow ensurepip to work without bundled wheels
type: enhancement
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue42022>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38989] pip install selects 32 bit wheels for 64 bit python if vcvarsall.bat amd64_x86 in environment

[Vinay Sajip]

Vinay Sajip  added the comment:

FYI I'm in the process of updating distlib to add the get_platform() / 
get_host_platform() distinction. The next release should have it.

--
keywords: +3.5regression

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38989] pip install selects 32 bit wheels for 64 bit python if vcvarsall.bat amd64_x86 in environment

[Steve Dower]

Steve Dower  added the comment:

I'm closing this as external, as the canonical source for platform tags is now 
the packaging library.

Either pip and/or distlib should switch to using that library or the logic 
included (which I'll note is considerably more complex - but also more well 
defined and tested - than what is in distutils).

--
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38989] pip install selects 32 bit wheels for 64 bit python if vcvarsall.bat amd64_x86 in environment

[Kyle Altendorf]

Change by Kyle Altendorf :


--
nosy: +altendky

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38989] pip install selects 32 bit wheels for 64 bit python if vcvarsall.bat amd64_x86 in environment

[Steve Dower]

Steve Dower  added the comment:

> maybe you have some relevant context

Nothing you haven't figured out yourself. As you say, they're both private 
functions, and as we investigated adding a "get_target_platform" function, it 
turned out that nearly all users were expecting the target platform, so rather 
than updating everything we added one for the less-common case.

get_host_platform was not defined before, so I'd say use it if it's there and 
use get_platform if it's not.

I doubt we're going to add any new public/supported APIs to distutils ever 
again, to be honest.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38989] pip install selects 32 bit wheels for 64 bit python if vcvarsall.bat amd64_x86 in environment

[Kevin Puetz]

Change by Kevin Puetz :


--
nosy: +vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38989] pip install selects 32 bit wheels for 64 bit python if vcvarsall.bat amd64_x86 in environment

[Kevin Puetz]

Kevin Puetz  added the comment:

Just to link the various pieces together: I think 

https://bitbucket.org/pypa/distlib/src/2d145da7cb42590039fbd56a9ab764d5d4716a98/distlib/wheel.py#lines-53

is the place in distlib that's being breaking pip due to redefining 
distutils.util.get_platform() as the cross-compile target architecture  rather 
than the build architecture.

https://docs.python.org/3/distutils/apiref.html doesn't show it as a documented 
public function, but the commit Ryan linked did introduce a new 
get_host_plaform() that matches the old behavior; if that became public and 
distlib used itinstead (conditional on the python version?) that would also be 
a way to fix the symptom Ryan noted (pip now choosing the wrong wheel to 
install).

I don't know how the pieces here fit together well enough to now which side 
should change.

@zooba: adding you to the Cc since it was your comments at 
https://github.com/python/cpython/pull/11774#discussion_r254461961 that seem to 
have led to the decision to re-define get_platform, maybe you have some 
relevant context?

--
nosy: +steve.dower

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38989] pip install selects 32 bit wheels for 64 bit python if vcvarsall.bat amd64_x86 in environment

[Kevin Puetz]

Kevin Puetz  added the comment:

Besides the fact the MSVC's target platform isn't really related to the 
architecture for dependencies being installed, I'm not sure VSCMD_ARG_TGT_ARCH 
is an appropriate variable to look at in the first place. It doesn't seem to be 
at all documented, and (from looking at the implemenation) it seems to be meant 
as how parse_cmd.bat communicates with vcvars.bat, dotnet.bat, winsdk.bat, etc 
(these are all sub-programms that make up vcvarsall.bat)

I think %PLATFORM% (which generally ends up set equal to %VSCMD_ARG_TGT_ARCH% 
once vsdevcmd\ext\vcvars.bat has done its thing) is might be a better variable 
that cross-compiling should actually look at when it wants to know what 
architecture MSVC will compile to.

--
nosy: +puetzk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38989] pip install selects 32 bit wheels for 64 bit python if vcvarsall.bat amd64_x86 in environment

[Ryan Thornton]

New submission from Ryan Thornton :

## Expected Behavior

pip install should download dependencies matching the architecture of the 
python executable being used.

## Actual Behavior

When calling pip install from a Visual Studio command prompt configured to 
cross compile from x64 to x86, pip installs wheels matching the architecture of 
Visual Studio's cross compile target (i.e. `VSCMD_ARG_TGT_ARCH=x86`) and not 
the architecture of python itself (x64).

This results in a broken installation of core libraries.

## Steps to Reproduce

System Details:
Windows 10 x64
Python 3.8 x64
Visual Studio 2017 15.9.14

Environment Details:
vcvarsall.bat amd64_x86

1. "C:\Program Files\Python38\python.exe" -mvenv "test"
2. cd test\Scripts
3. pip install cffi==1.13.2

Results in the following:

> Collecting cffi
>  Using cached 
> https://files.pythonhosted.org/packages/f8/26/5da5cafef77586e4f7a136b8a24bc81fd2cf1ecb71b6ec3998ffe78ea2cf/cffi-1.13.2-cp38-cp38-win32.whl

## Context

I think the regression was introduced here:
62dfd7d6fe11bfa0cd1d7376382c8e7b1275e38c

https://github.com/python/cpython/commit/62dfd7d6fe11bfa0cd1d7376382c8e7b1275e38c

--
components: Distutils
messages: 357936
nosy: Ryan Thornton, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: pip install selects 32 bit wheels for 64 bit python if vcvarsall.bat 
amd64_x86 in environment
type: behavior
versions: Python 3.8

___
Python tracker 
<https://bugs.python.org/issue38989>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

(yet another) PEP idea to tackle binary wheels problem efficiently

[Alexander Revin]

Hi all,

I've been thoroughly reading various discussions, such as [1], [2] and
related ones regarding PEP 425, PEP 491 and PEP 513. I also happen to
use musl sometimes, so as discussed here [3] I thought it would be a
good idea to submit a new PEP regarding musl compatibility.

It's not a secret that everyday wheel usage on Linux is far from
perfect. Some packages are trying to compile when there's no compiler
on the system available, some rely on 3rd-party deps and explode when
they cannot find required headers installed and so on. Add to this
cross-compilation support (quite complicated) and distros like Alpine
or just something not using x86 (how many piwheels.org-like should
emerge for each non-x86 platform?). For example, I would like to
seamlessly install numpy, pandas and scikit onto ppc machine running
Gentoo musl and not waste 1 hour for compilation, or "just" use them
in x86 standard alpine-based docker image (basically what [3] is all
about).

Long story short, current wheel filename format:

{distribution}-{version}(-{build tag})?-{python tag}-{abi
tag}-{platform tag}.whl.

Doesn't not properly express package expectation. Let's take a look at
pandas wheels ([4]):

pandas-0.24.1-cp36-cp36m-manylinux1_x86_64.whl
pandas-0.24.1-cp36-cp36m-win_amd64.whl
pandas-0.24.1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl

I see issues with each of them:
1. First one won't work on Alpine or any musl-based distro;
2. Second – how amd64 is different from x86_64?
3. Third's platform tag is just a nightmare.

More of that, if you open the last one and inspect one of the
libraries, you'll find that:
$ file _libs/algos.cpython-36m-darwin.so
_libs/algos.cpython-36m-darwin.so: Mach-O universal binary with 2
architectures: [i386:Mach-O bundle i386] [x86_64]
_libs/algos.cpython-36m-darwin.so (for architecture i386): Mach-O bundle i386
_libs/algos.cpython-36m-darwin.so (for architecture x86_64): Mach-O
64-bit bundle x86_64

It's universal library! So not x86_64 only, as mentioned in the quite
long macosx_10_various platform tag.

TL;DR What my solution? To use something widely called "Target
Triplet" [5], omitting usual "vendor" field, so
{platform tag} from PEP 435 will have the format of _[_]:

pandas-0.24.1-cp36-cp36m-x86_64_linux_gnu.whl
pandas-0.24.1-cp36-cp36m-x86_64_linux_musl.whl
pandas-0.24.1-cp36-cp36m-x86_windows.whl
pandas-0.24.1-cp36-cp36m-x86_64_windows_msvs2010.whl
pandas-0.24.1-cp36-cp36m-x86_macosx_10_6.whl <-- won't be used for
anything Mojave+, see [6]
pandas-0.24.1-cp36-cp36m_aarch64_netbsd.whl

Primary concerns here:
- Arch and os are specified more consistently;
- Environment is specified only when needed;
- Lots of possible combinations of os and env are possible :)

Since most runtimes are hardcoded during build time anyway and changed
for each Python release, explicit versioning shouldn't be a problem.

JavaScript and Rustlang [7] use similar naming scheme. Though I don't
like both of them, at least portability of extensions looks less
broken than of Python (I've worked on native Nodejs extension in the
past).


What do you think?

Thanks,
Alex

[1] 
https://mail.python.org/archives/list/distutils-...@python.org/thread/KCLRIN4PTUGZLLL7GOUM23S46ZZ2D4FU/
[2] https://github.com/pypa/packaging-problems/issues/69
[3] https://github.com/pypa/manylinux/issues/37
[4] https://pypi.org/project/pandas/#files
[5] https://wiki.osdev.org/Target_Triplet
[6] https://support.apple.com/en-us/HT208436
[7] https://doc.rust-lang.org/reference/conditional-compilation.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: (yet another) PEP idea to tackle binary wheels problem efficiently

[Alexander Revin]

Two minor typos: platform tag should be separated by "-", not "_".
Also it makes sense to use "amd64" instead of "x86_64", so platform
can be just split by "_"

On Sat, Feb 16, 2019 at 9:29 PM Alexander Revin  wrote:
>
> Hi all,
>
> I've been thoroughly reading various discussions, such as [1], [2] and
> related ones regarding PEP 425, PEP 491 and PEP 513. I also happen to
> use musl sometimes, so as discussed here [3] I thought it would be a
> good idea to submit a new PEP regarding musl compatibility.
>
> It's not a secret that everyday wheel usage on Linux is far from
> perfect. Some packages are trying to compile when there's no compiler
> on the system available, some rely on 3rd-party deps and explode when
> they cannot find required headers installed and so on. Add to this
> cross-compilation support (quite complicated) and distros like Alpine
> or just something not using x86 (how many piwheels.org-like should
> emerge for each non-x86 platform?). For example, I would like to
> seamlessly install numpy, pandas and scikit onto ppc machine running
> Gentoo musl and not waste 1 hour for compilation, or "just" use them
> in x86 standard alpine-based docker image (basically what [3] is all
> about).
>
> Long story short, current wheel filename format:
>
> {distribution}-{version}(-{build tag})?-{python tag}-{abi
> tag}-{platform tag}.whl.
>
> Doesn't not properly express package expectation. Let's take a look at
> pandas wheels ([4]):
>
> pandas-0.24.1-cp36-cp36m-manylinux1_x86_64.whl
> pandas-0.24.1-cp36-cp36m-win_amd64.whl
> pandas-0.24.1-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
>
> I see issues with each of them:
> 1. First one won't work on Alpine or any musl-based distro;
> 2. Second – how amd64 is different from x86_64?
> 3. Third's platform tag is just a nightmare.
>
> More of that, if you open the last one and inspect one of the
> libraries, you'll find that:
> $ file _libs/algos.cpython-36m-darwin.so
> _libs/algos.cpython-36m-darwin.so: Mach-O universal binary with 2
> architectures: [i386:Mach-O bundle i386] [x86_64]
> _libs/algos.cpython-36m-darwin.so (for architecture i386): Mach-O bundle i386
> _libs/algos.cpython-36m-darwin.so (for architecture x86_64): Mach-O
> 64-bit bundle x86_64
>
> It's universal library! So not x86_64 only, as mentioned in the quite
> long macosx_10_various platform tag.
>
> TL;DR What my solution? To use something widely called "Target
> Triplet" [5], omitting usual "vendor" field, so
> {platform tag} from PEP 435 will have the format of _[_]:
>
> pandas-0.24.1-cp36-cp36m-x86_64_linux_gnu.whl
> pandas-0.24.1-cp36-cp36m-x86_64_linux_musl.whl
> pandas-0.24.1-cp36-cp36m-x86_windows.whl
> pandas-0.24.1-cp36-cp36m-x86_64_windows_msvs2010.whl
> pandas-0.24.1-cp36-cp36m-x86_macosx_10_6.whl <-- won't be used for
> anything Mojave+, see [6]
> pandas-0.24.1-cp36-cp36m_aarch64_netbsd.whl
>
> Primary concerns here:
> - Arch and os are specified more consistently;
> - Environment is specified only when needed;
> - Lots of possible combinations of os and env are possible :)
>
> Since most runtimes are hardcoded during build time anyway and changed
> for each Python release, explicit versioning shouldn't be a problem.
>
> JavaScript and Rustlang [7] use similar naming scheme. Though I don't
> like both of them, at least portability of extensions looks less
> broken than of Python (I've worked on native Nodejs extension in the
> past).
>
>
> What do you think?
>
> Thanks,
> Alex
>
> [1] 
> https://mail.python.org/archives/list/distutils-...@python.org/thread/KCLRIN4PTUGZLLL7GOUM23S46ZZ2D4FU/
> [2] https://github.com/pypa/packaging-problems/issues/69
> [3] https://github.com/pypa/manylinux/issues/37
> [4] https://pypi.org/project/pandas/#files
> [5] https://wiki.osdev.org/Target_Triplet
> [6] https://support.apple.com/en-us/HT208436
> [7] https://doc.rust-lang.org/reference/conditional-compilation.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Building manylinux wheels & auditwheel

[Patrick Young]

Hello,

I've been exploring building manylinux wheels and trying to use auditwheel
to vendorize my shared libraries.  Essentially, I can't seem to get
"auditwheel repair" to fix up my wheel that has some dependencies that need
to be packed up.

I've described my problem at https://github.com/pypa/auditwheel/issues/52,
but to summarize, I've built the demo wheel found at
https://github.com/pypa/python-manylinux-demo.  From inside the container,
after the wheel's have been built but not repaired, I run

auditwheel -vv show python_manylinux_demo-1.0-cp27-cp27mu-linux_x86_64.whl

which gives the following:

DEBUG:auditwheel.wheel_abi:{}
DEBUG:auditwheel.policy.versioned_symbols:Required symbol versions: {}
INFO:auditwheel.wheel_abi:{
"manylinux1_x86_64": {
"priority": 100,
"libs": {}
},
"linux_x86_64": {
"priority": 0,
"libs": {}
}
}
DEBUG:auditwheel.wheel_abi:external referene info
DEBUG:auditwheel.wheel_abi:{
"manylinux1_x86_64": {
"priority": 100,
"libs": {}
},
"linux_x86_64": {
"priority": 0,
"libs": {}
}
}

python_manylinux_demo-1.0-cp27-cp27mu-linux_x86_64.whl is consistent
with the following platform tag: "manylinux1_x86_64".

The wheel references no external versioned symbols from system-
provided shared libraries.

The wheel requires no external shared libraries! :)

but unzipping that wheel and runnning ldd tells a different story

[root@1965501e43ea pymanylinuxdemo]# ldd extension.so
linux-vdso.so.1 =>  (0x7ffc52bd8000)
libcblas.so.3 => /usr/lib64/atlas/libcblas.so.3 (0x7fdcd467e000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7fdcd4461000)
libc.so.6 => /lib64/libc.so.6 (0x7fdcd4108000)
libatlas.so.3 => /usr/lib64/atlas/libatlas.so.3 (0x7fdcd3813000)
libm.so.6 => /lib64/libm.so.6 (0x7fdcd358f000)
/lib64/ld-linux-x86-64.so.2 (0x5619467b3000)

Any help would be greatly appreciated! I'm experiencing the same thing
across the board with other builds I've been trying to manylinuxize.


Thanks!

-Patrick
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Packaging multiple wheels in the same package

[Nir Cohen]

Appreciate it! Will do!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Packaging multiple wheels in the same package

[Ethan Furman]

On 07/13/2016 05:54 AM, Nir Cohen wrote:

On Thursday, July 7, 2016 at 7:47:22 AM UTC+3, Nir Cohen wrote:

On Wednesday, July 6, 2016 at 10:09:01 PM UTC+3, Ethan Furman wrote:

On 07/06/2016 11:43 AM, Nir Cohen wrote:



We decided that we want to package sets of wheels together created or downloaded

  > by `pip wheel`, add relevant metadata, package them together into a
single archive
  > (tar.gz or zip) and use the same tool which packs them up to install
them later on,
  > on the destination hosts.


We came up with a tool (http://github.com/cloudify-cosmo/wagon) to do just that

  > and that's what we currently use to create and install our plugins.



Sorry to bump this up.. but I'm not sure exactly how I should go about getting 
as much feedback as possible on this. Any suggestions?


You could try Python-Ideas -- plenty of debate happens on that list. ;)

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Packaging multiple wheels in the same package

[Chris Angelico]

On Wed, Jul 13, 2016 at 10:54 PM, Nir Cohen <nir...@gmail.com> wrote:
> On Thursday, July 7, 2016 at 7:47:22 AM UTC+3, Nir Cohen wrote:
>> On Wednesday, July 6, 2016 at 10:09:01 PM UTC+3, Ethan Furman wrote:
>> > Sounds like a great idea!
>> >
>> > Once you have your feed-back from here you'll want to take your PEP over
>> > to the dist-utils sig:
>> >
>> > https://mail.python.org/mailman/listinfo/distutils-sig
>> >
>> > --
>> > ~Ethan~
>>
>> Happy to hear :)
>>
>> btw, pull requests are certainly welcome to make whichever changes required 
>> to make Wagon PEP-worthy.
>
> Sorry to bump this up.. but I'm not sure exactly how I should go about 
> getting as much feedback as possible on this. Any suggestions?

Well a lot of the people here might *use* wheels, but a relatively
small proportion *create* them. (I'm not big on creating packages -
the only PyPI-published module of mine is a tiny pure-Python one, so
it's about as simple as it gets. And it's not even actively maintained
any more.) Ethan suggested hopping over to distutils-sig - have you
done that? That would be the next step, if you haven't.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Packaging multiple wheels in the same package

[Nir Cohen]

On Thursday, July 7, 2016 at 7:47:22 AM UTC+3, Nir Cohen wrote:
> On Wednesday, July 6, 2016 at 10:09:01 PM UTC+3, Ethan Furman wrote:
> > On 07/06/2016 11:43 AM, Nir Cohen wrote:
> > 
> > > We decided that we want to package sets of wheels together created or 
> > > downloaded
> >  > by `pip wheel`, add relevant metadata, package them together into a 
> > single archive
> >  > (tar.gz or zip) and use the same tool which packs them up to install 
> > them later on,
> >  > on the destination hosts.
> > >
> > > We came up with a tool (http://github.com/cloudify-cosmo/wagon) to do 
> > > just that
> >  > and that's what we currently use to create and install our plugins.
> > 
> > Sounds like a great idea!
> > 
> > Once you have your feed-back from here you'll want to take your PEP over 
> > to the dist-utils sig:
> > 
> > https://mail.python.org/mailman/listinfo/distutils-sig
> > 
> > --
> > ~Ethan~
> 
> Happy to hear :)
> 
> btw, pull requests are certainly welcome to make whichever changes required 
> to make Wagon PEP-worthy.


Sorry to bump this up.. but I'm not sure exactly how I should go about getting 
as much feedback as possible on this. Any suggestions?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Packaging multiple wheels in the same package

[Nir Cohen]

On Wednesday, July 6, 2016 at 10:09:01 PM UTC+3, Ethan Furman wrote:
> On 07/06/2016 11:43 AM, Nir Cohen wrote:
> 
> > We decided that we want to package sets of wheels together created or 
> > downloaded
>  > by `pip wheel`, add relevant metadata, package them together into a 
> single archive
>  > (tar.gz or zip) and use the same tool which packs them up to install 
> them later on,
>  > on the destination hosts.
> >
> > We came up with a tool (http://github.com/cloudify-cosmo/wagon) to do just 
> > that
>  > and that's what we currently use to create and install our plugins.
> 
> Sounds like a great idea!
> 
> Once you have your feed-back from here you'll want to take your PEP over 
> to the dist-utils sig:
> 
> https://mail.python.org/mailman/listinfo/distutils-sig
> 
> --
> ~Ethan~

Happy to hear :)

btw, pull requests are certainly welcome to make whichever changes required to 
make Wagon PEP-worthy.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Packaging multiple wheels in the same package

[Ethan Furman]

On 07/06/2016 11:43 AM, Nir Cohen wrote:


We decided that we want to package sets of wheels together created or downloaded
> by `pip wheel`, add relevant metadata, package them together into a 
single archive
> (tar.gz or zip) and use the same tool which packs them up to install 
them later on,

> on the destination hosts.


We came up with a tool (http://github.com/cloudify-cosmo/wagon) to do just that

> and that's what we currently use to create and install our plugins.

Sounds like a great idea!

Once you have your feed-back from here you'll want to take your PEP over 
to the dist-utils sig:


   https://mail.python.org/mailman/listinfo/distutils-sig

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Packaging multiple wheels in the same package

[Nir Cohen]

Hey all,

As part of working on Cloudify (http://github.com/cloudify-cosmo) we've had to 
provide a way for customers to install our plugins in an environment where PyPI 
isn't accessible. These plugins are sets of Python packages which necessarily 
depend on one another (i.e. a regular python package with dependencies).

We decided that we want to package sets of wheels together created or 
downloaded by `pip wheel`, add relevant metadata, package them together into a 
single archive (tar.gz or zip) and use the same tool which packs them up to 
install them later on, on the destination hosts.

We came up with a tool (http://github.com/cloudify-cosmo/wagon) to do just that 
and that's what we currently use to create and install our plugins.

While wheel solves the problem of generating wheels, there is no single, 
standard method for taking an entire set of dependencies packaged in a single 
location and installing them in a different location.

We thought it would be a good idea to propose a PEP for that and wanted to get 
your feedback before we start writing the proposal.

The logic behind the PEP is that there's a standard for creating a single 
python package and we would like to propose a layer above it to package 
multiple python packages either for offline environments or any other 
requirement a user may have.

We're currently working on a new rearchitected version of that tool to make it 
more pythonic and clean but the base stays the same.


We would greatly appreciate your feedback on this.

Thanks!


P.S. We encourage you to take a look at the repo (see the `rearchitecture` 
branch) and read the README.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Wheels For ...

[Sven R. Kunze]

On 06.09.2015 22:06, Ned Batchelder wrote:

As a developer of a Python package, I don't see how this would be better.
The developer would still have to get their software into some kind of
uniform configuration, so the central authority could package it.  You've
moved the problem from, "everyone has to make wheels" to "everyone has to
make a tree that's structured properly."  But if we can do the second
thing, the first thing is really easy.
Unfortunately, I disagree with you one that and others already gave 
explanations why.



Internally, we had this "wild-west" tree in our source as well but we 
moved on to a properly structured tree and it solved problems we didn't 
even imagine to have solved when starting this effort some years ago.



Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list

Re: Wheels For ...

[Ned Batchelder]

On Sunday, September 6, 2015 at 1:33:58 PM UTC-4, Sven R. Kunze wrote:
> 
> Why do developers need to build their distribution themselves?
> 
> ...
> 
> With this post, I would like raise awareness of the people in charge of 
> the Python infrastructure.

Sven, you ask a question, and then say you are trying to raise awareness.
Are you making a proposal?  It sounds like you might be implying that it
would be better if some central infrastructure group could make all the
distributions?

As a developer of a Python package, I don't see how this would be better.
The developer would still have to get their software into some kind of
uniform configuration, so the central authority could package it.  You've
moved the problem from, "everyone has to make wheels" to "everyone has to
make a tree that's structured properly."  But if we can do the second
thing, the first thing is really easy.

Maybe I've misunderstood?

--Ned.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Wheels For ...

[Laura Creighton]

In a message of Sun, 06 Sep 2015 15:31:16 -0400, Terry Reedy writes:
>On 9/6/2015 1:33 PM, Sven R. Kunze wrote:
>>
>> With this post, I would like raise awareness of the people in charge of
>> the Python infrastructure.
>
>pypa is in charge of packaging. https://github.com/pypa
>I believe the google groups link is their discussion forum.

They have one -- https://groups.google.com/forum/#!forum/pypa-dev
but you can also get them at the disutils mailing list.
https://mail.python.org/mailman/listinfo/distutils-sig

I think, rather than discussion, it is 'people willing to write code'
that they are short of ...

Laura

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Python-ideas] Wheels For ...

[Matthias Bussonnier]

Hi Sven,

Just adding a few comments inline:

On Sun, Sep 6, 2015 at 7:33 PM, Sven R. Kunze <srku...@mail.de> wrote:

> 3) more than one way to do (upload, wheel, source/binary etc.) it (sigh)

And most are uploading/registering over http (sight)

> nope: what a pity for wheels; example:
> https://github.com/simplejson/simplejson/issues/122

But that's for non pure-python wheels,
wheel can be universal, in which case they are easy to build.

> Why do developers need to build their distribution themselves?

Historical reason. On GitHub, at least it is pretty easy to make Travis-CI
build your wheels, some scientific packages (which are not the easier to build)
have done that, so automation is  possible. And these case need really
particular environements where all aspects of the builds are controlled.

>
> I had not real answer to him, but pondering a while over it, I found it
> really insightful. Viewing this from a different angle, packaging your own
> distribution is actually a waste of time. It is a tedious, error-prone task
> involving no creativity whatsoever. Developers on the other hand are
> actually people with very little time and a lot of creativity at hand which
> should spend better. The logical conclusion would be that PyPI should build
> wheels for the developers for every python/platform combination necessary.

I think that some of that could be done by warehouse at some point:
https://github.com/pypa/warehouse

But you will never be able to cover all. I'm sure people will ask PyPI
to build for windows 98 server version otherwise.

Personally for pure python packages I know use https://pypi.python.org/pypi/flit
which is one of the only packaging tools for which I can remember all the
step to get a package on PyPI without reading the docs.

-- 
M

[Sven, sorry for duplicate :-) ]
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Python-ideas] Wheels For ...

[Ryan Gonzalez]

On September 6, 2015 12:33:29 PM CDT, "Sven R. Kunze" <srku...@mail.de> wrote:
>Hi folks,
>
>currently, I came across http://pythonwheels.com/ during researching
>how 
>to make a proper Python distribution for PyPI. I thought it would be 
>great idea to tell other maintainers to upload their content as wheels 
>so I approached a couple of them. Some of them already provided wheels.
>
>Happy being able to have built my own distribution, I discussed the 
>issue at hand with some people and I would like to share my findings
>and 
>propose some ideas:
>
>1) documentation is weirdly split up/distributed and references old
>material
>2) once up and running (setup.cfg, setup.py etc. etc.) it works but 
>everybody needs to do it on their own
>3) more than one way to do (upload, wheel, source/binary etc.) it
>(sigh)
>4) making contact to propose wheels on github or per email is easy 
>otherwise almost impossible or very tedious
>5) reactions went evenly split from "none", "yes", "when ready" to
>"nope"
>
>None: well, okay
>yes: that's good
>when ready: well, okay
>nope: what a pity for wheels; example: 
>https://github.com/simplejson/simplejson/issues/122
>
>I personally find the situation not satisfying. Someone proposes the 
>following solution in form of a question:
>
>Why do developers need to build their distribution themselves?
>
>I had not real answer to him, but pondering a while over it, I found it
>
>really insightful. Viewing this from a different angle, packaging your 
>own distribution is actually a waste of time. It is a tedious, 
>error-prone task involving no creativity whatsoever. Developers on the 
>other hand are actually people with very little time and a lot of 
>creativity at hand which should spend better. The logical conclusion 
>would be that PyPI should build wheels for the developers for every 
>python/platform combination necessary.
>

You can already do this with CI services. I wrote a post about doing that with 
AppVeyor:

http://kirbyfan64.github.io/posts/using-appveyor-to-distribute-python-wheels.html

but the idea behind it should apply easily to Travis and others. In reality, 
you're probably using a CI service to run your tests anyway, so it might as 
well build your wheels, too!

>
>With this post, I would like raise awareness of the people in charge of
>
>the Python infrastructure.
>
>
>Best,
>Sven
>___
>Python-ideas mailing list
>python-id...@python.org
>https://mail.python.org/mailman/listinfo/python-ideas
>Code of Conduct: http://python.org/psf/codeofconduct/

-- 
Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Wheels For ...

[Mark Lawrence]

On 06/09/2015 20:31, Terry Reedy wrote:

On 9/6/2015 1:33 PM, Sven R. Kunze wrote:

With this post, I would like raise awareness of the people in charge of
the Python infrastructure.


pypa is in charge of packaging. https://github.com/pypa
I believe the google groups link is their discussion forum.



Or gmane.comp.python.pypa.devel

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Wheels For ...

[Sven R. Kunze]

Hi folks,

currently, I came across http://pythonwheels.com/ during researching how 
to make a proper Python distribution for PyPI. I thought it would be 
great idea to tell other maintainers to upload their content as wheels 
so I approached a couple of them. Some of them already provided wheels.


Happy being able to have built my own distribution, I discussed the 
issue at hand with some people and I would like to share my findings and 
propose some ideas:


1) documentation is weirdly split up/distributed and references old material
2) once up and running (setup.cfg, setup.py etc. etc.) it works but 
everybody needs to do it on their own

3) more than one way to do (upload, wheel, source/binary etc.) it (sigh)
4) making contact to propose wheels on github or per email is easy 
otherwise almost impossible or very tedious

5) reactions went evenly split from "none", "yes", "when ready" to "nope"

None: well, okay
yes: that's good
when ready: well, okay
nope: what a pity for wheels; example: 
https://github.com/simplejson/simplejson/issues/122


I personally find the situation not satisfying. Someone proposes the 
following solution in form of a question:


Why do developers need to build their distribution themselves?

I had not real answer to him, but pondering a while over it, I found it 
really insightful. Viewing this from a different angle, packaging your 
own distribution is actually a waste of time. It is a tedious, 
error-prone task involving no creativity whatsoever. Developers on the 
other hand are actually people with very little time and a lot of 
creativity at hand which should spend better. The logical conclusion 
would be that PyPI should build wheels for the developers for every 
python/platform combination necessary.



With this post, I would like raise awareness of the people in charge of 
the Python infrastructure.



Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list

Re: Wheels For ...

[Terry Reedy]

On 9/6/2015 1:33 PM, Sven R. Kunze wrote:

Hi folks,

currently, I came across http://pythonwheels.com/ during researching how
to make a proper Python distribution for PyPI. I thought it would be
great idea to tell other maintainers to upload their content as wheels
so I approached a couple of them. Some of them already provided wheels.

Happy being able to have built my own distribution, I discussed the
issue at hand with some people and I would like to share my findings and
propose some ideas:

1) documentation is weirdly split up/distributed and references old
material
2) once up and running (setup.cfg, setup.py etc. etc.) it works but
everybody needs to do it on their own
3) more than one way to do (upload, wheel, source/binary etc.) it (sigh)
4) making contact to propose wheels on github or per email is easy
otherwise almost impossible or very tedious
5) reactions went evenly split from "none", "yes", "when ready" to "nope"

None: well, okay
yes: that's good
when ready: well, okay
nope: what a pity for wheels; example:
https://github.com/simplejson/simplejson/issues/122

I personally find the situation not satisfying. Someone proposes the
following solution in form of a question:

Why do developers need to build their distribution themselves?

I had not real answer to him, but pondering a while over it, I found it
really insightful. Viewing this from a different angle, packaging your
own distribution is actually a waste of time. It is a tedious,
error-prone task involving no creativity whatsoever. Developers on the
other hand are actually people with very little time and a lot of
creativity at hand which should spend better. The logical conclusion
would be that PyPI should build wheels for the developers for every
python/platform combination necessary.


With this post, I would like raise awareness of the people in charge of
the Python infrastructure.


pypa is in charge of packaging. https://github.com/pypa
I believe the google groups link is their discussion forum.

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

devpi-1.1: improved pypi cache, data migration, wheels, ...

[holger krekel]

The devpi-{server,client}-1.1 releases bring a lot of refinements
and improvements for serving standalone pypi mirrors or company/private
indexes which seemlessly merge in PyPI releases, mainly:

- improved speed and semantics of pypi cache.  devpi-server
  has been tested to correctly mirror all ~34000 projects
  on pypi.python.org now, and minimizes upstream interactions
  by fully exploiting the existing mirroring protocols.

- data migration: new --upgrade/import/export options.
  versioning of serverstate and API calls so that future
  changes can be detected by clients.

- better support for .whl files and many other little 
  improvements and bug fixes, see the changelog
  below for more info.

Note that devpi-1.1 will require to ``--upgrade`` your 1.0 
server state before you can serve with devpi-server-1.1 release.

Docs also were updated.  Here is a Quickstart tutorial 
for efficient pypi-mirroring on your laptop:: 

http://doc.devpi.net/1.1/quickstart-pypimirror.html

And if you want to manage your releases or implement staging
as an individual or within an organisation::

http://doc.devpi.net/1.1/quickstart-releaseprocess.html

If you want to permanently install devpi-server and potentially
access it from many clients::

http://doc.devpi.net/1.1/quickstart-server.html

More documentation and the beginning of an exhaustive user manual::

http://doc.devpi.net/latest/

have fun,

holger


CHANGELOG 1.1


devpi-server:

- systematically test pypi/mirror code against all 34K pypi projects
  so that we know that all http/https installable archive links that pypi 
offers 
  are correctly recognized by devpi-server's root/pypi index.

- if no pypi mirror state is known, devpi-server now calls
  pypi to obtain names/serials.  It will fail to start
  if no such initial connection is possible.  Once a first mirror
  state is known, subsequent devpi-server starts will
  not perform this initial query.

- speed up and make more reliable all operations on private packages which
  have no pypi.python.org release: we can now determine if a project
  exists on pypi and under which name exactly without
  remote queries or redirects to pypi.python.org.

- fix issue45: register/upload package names are now properly 
  validated and redirects take place if e.g. a project was
  registered as name-sub and +simple/name_sub is queried.

- new --upgrade-state command to allow for easy and safe
  in-place upgrading of server state.  This is not guranteed
  to be possible for all future releases which might require
  using --export with an older version and --import with a newer
  version.

- new --export/--import options to dump and import server contents:
  users, indexes, docs, release files and (test) attachments.
  Note that root/pypi (PyPI-caching information) will not be exported/imported.
  (maybe in the future if there is demand). 

- fix issue49: both push and import/export now support docfiles.  Note,
  however, that docfiles relate to a project as a whole and are not tied
  to a particular version.  This property is inherited from the PyPI
  standard upload_docs action and cannot be changed without interfering
  or replacing the upload_docs protocol of setuptools/sphinx.

- fix issue51: return 200 code if release file is successfully uploaded 
  but jenkins could not be triggered (previously returned 500)

- reject simple/NAME if NAME contains non-ascii characters
  (PEP426 naming rules)

- devpi-server now returns a X-DEVPI-API-VERSION and
  X-DEVPI-SERVER-VERSION header.  For future incompatible changes 
  these versions allow clients to reject interactions.

- also add .serverversion file and write it if it does not
  exist, and make devpi-server use it to verify if
  operating on a compatible server data layout, otherwise bail out.

- address issue43: --gendeploy now uses pip without --pre and
  explicitely instructs pip to install the exact same version 
  of devpi-server with which --gendeploy is issued.

- fix issue46 -- for GET /root/pypi/ only show a link to the
  simple page instead of computing latest in-stage packages
  which is only useful for devpi's user indices.

- fix issue37: upload with expired login causes proper 401


devpi-client:

- detect X-DEVPI-API-VERSION header and check for compatibility.
  devpi-client currently supports version 1 and warns if
  no version is known (defaulting to 1).

-