Re: [Distutils] a package with is a module
On Mon, Oct 27, 2014 at 8:30 AM, Marius Gedminas wrote: > Many setup.py files fail if you run them when your working directory is > not the one where the setup.py resides itself. I think you can safely > rely on that implementation detail. > agreed, but if you really wanted to be sure you could use __file__ to get the path of the setup.y and go from there. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP425 - Wheel Binary Package Compatibility
In article , Olivier Grisel wrote: > Homebrew-installed Python and the system Python that comes by default > on OSX are binary compatible with wheels generated with Python from > the official OSX installer from python.org. > > In current versions of pip you "just" have to rename the wheel > filenames to get them picked up from PyPI on those platforms. > > This explains the strange names of the OSX wheels for numpy for instance: > > numpy-1.9.0-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.w > hl > numpy-1.9.0-cp33-cp33m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64. > whl > numpy-1.9.0-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64. > whl > > https://pypi.python.org/pypi/numpy > > macosx_10_9_x86_64 is the platform tag used by Homebrew-installed > Python while macosx_10_6_intel is the platform tag of the python.org > Python. To expand on this, the platform tag is generated by Python's Distutils and wheels use and expand on the pattern established by it. For OS X, the "10_x" part is based on the minimum OS X deployment target of the Python build, normally set by the compiler -mmacosx-version-min argument or the MACOSX_DEPLOYMENT_TARGET env variable at configure time (these are standard options supported by the Apple-supplied buildtool chains). That value is saved and used by Distutils in subsequent extension module builds, although you can override it to a higher (not lower) value for a particular build. The arch values in the tag also come from the configured universal architectures. Any Python configured the same way (wrt MACOSX_DEPLOYMENT_TARGET and archs) will supply the same platform tag. So there's nothing special about Homebrew or MacPorts or python.org or the Apple-supplied system Pythons; it is assumed that any identically configured Python will provide a compatible ABI for C extension modules. We also assume that Apple will provide backward compatibility on newer releases of OS X, such that, for example, an extension module compiled for 10.6 will run just fine on later OS X releases *and* will run with a Python configured for a later OS X release, assuming there is a non-zero intersection of universal archs between the interpreter and the extension module. In practice, those assumptions seems to have worked fairly well on OS X, starting from the beginning of universal arch support and at least up to now although they may break down in the future. It's still not perfect. For example, the platform string doesn't take into account the Python 2 --enable-unicode=ucs2/ucs4 build option; but ucs4 builds aren't widely used on OS X and Python 3 no longer has this problem. (For C++ extension modules, there also may be issues with Apple's change in default c++ libraries in OS X 10.9.) On Linux systems, it can be dangerous to make similar simplifying assumptions, with many more variables in play, much less reflected in the platform string. -- Ned Deily, n...@acm.org ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a package with is a module
> On Oct 28, 2014, at 2:20 PM, Ethan Furman wrote: > > On 10/27/2014 08:26 AM, Paul Moore wrote: >> On 27 October 2014 15:07, Ethan Furman wrote: >>> Paul Moore also declaimed: Alternatively, you could distribute all 3 files [...] >>> >>> The problem I have with this method is that the last time I tried it >>> setup.py attempted to pre-compile all the files, resulting in syntax errors, >>> which makes for a lousy user experience. >> >> Yeah, it's harmless but ugly. I've seen that issue myself. > > For the record, I thought setting PYTHONDONTWRITEBYTECODE from inside the > setup.py script: > > os.environ['PYTHONDONTWRITEBYTECODE'] = True > > might do the trick, but > > - it isn't available on 2.5 > - it doesn't work on 2.6 (didn't test on 2.7 nor 3.x) > > Oh well. Guess I'll include a note that says, "Ignore any syntax errors > during 'setup.py install', they're harmless." > > :( > > -- > ~Ethan~ > ___ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig I think the next version of pip might hide this unless an error in install actually occurs. I could be wrong though. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a package with is a module
On 10/27/2014 08:26 AM, Paul Moore wrote: On 27 October 2014 15:07, Ethan Furman wrote: Paul Moore also declaimed: Alternatively, you could distribute all 3 files [...] The problem I have with this method is that the last time I tried it setup.py attempted to pre-compile all the files, resulting in syntax errors, which makes for a lousy user experience. Yeah, it's harmless but ugly. I've seen that issue myself. For the record, I thought setting PYTHONDONTWRITEBYTECODE from inside the setup.py script: os.environ['PYTHONDONTWRITEBYTECODE'] = True might do the trick, but - it isn't available on 2.5 - it doesn't work on 2.6 (didn't test on 2.7 nor 3.x) Oh well. Guess I'll include a note that says, "Ignore any syntax errors during 'setup.py install', they're harmless." :( -- ~Ethan~ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP425 - Wheel Binary Package Compatibility
On 28.10.2014 11:13, Matthias Hafner wrote: > Hi there, > > Following up on > https://bitbucket.org/pypa/wheel/issue/124/glibc-incompatibility. > > How should we deal with incompatibility of dynamically linked libraries? > Doing "pip wheel numpy" on a Linux 64bit machine results in , which is > linked dynamically against the GLIBC version installed on the build > machine. > > So should the wheel be shipped with GLIBC, or the GLIBC version be > specified in the wheel name (means to build a new wheel for each GLIBC > version?). Also, maybe this is not the only library it is dynamically > linked against? > > Why does that work on MacOS, btw? Are all library versions fixed there for > one version of OSX? > > Thanks for putting some light into this issue. Since OSes typically ship with older libc versions, your best bet is to build the package on a OS release that's a few years older than the latest version, e.g. for Ubuntu you'd use 12.04 or even 10.04 instead of 14.04. On Linux, you can check the min required GLIBC version by looking at the nm output of the binaries. They will have a "@@GLIBC_x.x.x" modifier attached to the symbols loaded from the GLIBC. The platform module has a helper function which does this for you: https://docs.python.org/2.7/library/platform.html#platform.libc_ver That way you can avoid many incompatibilities with libc versions. This works on Mac OS X and other Unix-based systems as well. You may run into library version info problems, though: http://stackoverflow.com/questions/137773/what-does-the-no-version-information-available-error-from-linux-dynamic-linker/156387#156387 A way around this is to build on systems that don't yet include this version information. The alternative is static linking, but this is often not possible or desired. On Windows you have to use the libc versions that were used to compile Python itself, so things are easier. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 28 2014) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2014-10-24: Released eGenix pyOpenSSL 0.13.5 ... http://egenix.com/go63 : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] "not a supported wheel on this platform"
On 28 October 2014 15:15, Antoine Pitrou wrote: > Apparently already reported to pip :-) > https://github.com/pypa/pip/issues/1870 I *knew* I'd seen it somewhere. Thanks for locating it. > Reported to wheel at > https://bitbucket.org/pypa/wheel/issue/125/get_supported-should-return-more And thanks again. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP425 - Wheel Binary Package Compatibility
2014-10-28 16:22 GMT+01:00 Olivier Grisel : > Here is a test matrix that checks binary compatibility of OSX wheels > for many projects of the SciPy stack: > > https://github.com/MacPython/scipy-stack-osx-testing And here are the results: https://travis-ci.org/MacPython/scipy-stack-osx-testing -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP425 - Wheel Binary Package Compatibility
Here is a test matrix that checks binary compatibility of OSX wheels for many projects of the SciPy stack: https://github.com/MacPython/scipy-stack-osx-testing -- Olivier ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP425 - Wheel Binary Package Compatibility
2014-10-28 15:04 GMT+01:00 Paul Moore : > On 28 October 2014 10:13, Matthias Hafner wrote: > > (in reverse order, easiest to hardest :-)) > >> Why does that work on MacOS, btw? Are all library versions fixed there for >> one version of OSX? > > I believe (I'm not 100% sure as I'm a Windows user not an OSX user) > that PyPI only supports binaries compatible with the official > python.org binaries of Python. So library version decisions are moot. > This means that homebrew or "the other ones" (sorry :-)) users can't > avail themselves of PyPI-hosted binaries yet, until the wider library > compatibility issues are resolved. Homebrew-installed Python and the system Python that comes by default on OSX are binary compatible with wheels generated with Python from the official OSX installer from python.org. In current versions of pip you "just" have to rename the wheel filenames to get them picked up from PyPI on those platforms. This explains the strange names of the OSX wheels for numpy for instance: numpy-1.9.0-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl numpy-1.9.0-cp33-cp33m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl numpy-1.9.0-cp34-cp34m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.whl https://pypi.python.org/pypi/numpy macosx_10_9_x86_64 is the platform tag used by Homebrew-installed Python while macosx_10_6_intel is the platform tag of the python.org Python. Off-course if your python extension link to non-system libraries, you have to embed them in the wheel, for instance using: https://pypi.python.org/pypi/delocate -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] "not a supported wheel on this platform"
On Tue, 28 Oct 2014 15:03:23 + Paul Moore wrote: > On 28 October 2014 14:51, Antoine Pitrou wrote: > > Does matching really happen that way? > > Unfortunately yes :-( > > get_supported() introspects the system you're installing on and builds > a list of tag combinations it's willing to accept. In doing so it > misses some that I'd consider obscure but reasonable (notably here, > independent of Python implementation (py rather than cp) but > architecture specific). I consider this a flawed design, but it's > always been like this. > > You'll need to raise a bug report for this. Actually two, as the > pep425tags code is in both pip and wheel independently (the one you > actually *want* is the pip one, though). Apparently already reported to pip :-) https://github.com/pypa/pip/issues/1870 Reported to wheel at https://bitbucket.org/pypa/wheel/issue/125/get_supported-should-return-more Thanks for the explanations. Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] toml
On Tue, Oct 28, 2014 at 07:43 -0700, Chris Jerdonek wrote: > On Tue, Oct 28, 2014 at 2:59 AM, holger krekel wrote: > > On Mon, Oct 27, 2014 at 16:45 -0400, Daniel Holth wrote: > >> I liked it because I agree with the TOML author that the YAML spec > >> gives rage; YAML seems to be defined as a bunch of things that the end > >> user is supposed to think are intuitive, but try understanding and > >> correctly parsing the full set of what is allowed... TOML on the other > >> hand is short. > > > > Don't know but TOML could work well as a user facing config syntax. > > Seems to be reasonably well defined and more expressive than plain ini > > files. Would be curious if it could be used for tox for example. > > Daniel, Holger, et al., what is wrong with ini out of curiosity? E.g. There are no types with normal ini files, so integers, strings, lists etc. all have to be done manually, i.e. without support from the parser. best, holger > Thanks, > --Chris > ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] "not a supported wheel on this platform"
On 28 October 2014 14:51, Antoine Pitrou wrote: > Does matching really happen that way? Unfortunately yes :-( get_supported() introspects the system you're installing on and builds a list of tag combinations it's willing to accept. In doing so it misses some that I'd consider obscure but reasonable (notably here, independent of Python implementation (py rather than cp) but architecture specific). I consider this a flawed design, but it's always been like this. You'll need to raise a bug report for this. Actually two, as the pep425tags code is in both pip and wheel independently (the one you actually *want* is the pip one, though). I know - this should really be fixed. I'd like to see pep425tags in a separate project, referenced (or vendored if necessary) from both pip and wheel. And I'd like a matching algorithm for checking tags rather than generating a list of valid values. Oh, and a pony :-) > Here it is anyway. There's no "py2" at all: Sorry, from any given Python you'll get either py2 or py3 depending on the major version of your Python. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP425 - Wheel Binary Package Compatibility
On Tue, Oct 28, 2014 at 10:13 AM, Matthias Hafner wrote: > Hi there, > > Following up on > https://bitbucket.org/pypa/wheel/issue/124/glibc-incompatibility. > > How should we deal with incompatibility of dynamically linked libraries? > Doing "pip wheel numpy" on a Linux 64bit machine results in , which is > linked dynamically against the GLIBC version installed on the build > machine. > Wheel by itself simply cannot deal with this, you need something more. Practically speaking, there is no such a thing as ABI on Linux: even if you somehow managed to deal with glibc, you would then need to deal with fortran ABI, then with C++ ABI, etc... Dealing with this at the python level is simply intractable. That needs to be handled at the distribution level, or within a "sumo distribution" like Anaconda from Continuum or Canopy from Enthought (disclaimer, I work for Enthought), which makes the problem more tractable by picking up an ABI and stick with it for the full set of packages. In theory, you can try to emulate this by building on the oldest version of each compiled library, and hope that your target platforms are ABI compatible with this, but that's hard on Linux. David > So should the wheel be shipped with GLIBC, or the GLIBC version be > specified in the wheel name (means to build a new wheel for each GLIBC > version?). Also, maybe this is not the only library it is dynamically > linked against? > > Why does that work on MacOS, btw? Are all library versions fixed there for > one version of OSX? > Yes. Same for windows. The native toolchains there are fairly easy to configure for targetting a specific minimum version. David > Thanks for putting some light into this issue. > > Best regards, > Matthias > > ___ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > > ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] twine: Binary wheel for an unsupported platform
On Tue, Oct 28, 2014 at 7:04 AM, Antoine Pitrou wrote:
>
> Hello,
>
> I guess I am doing something wrong, but what?
> (I took "linux_x86_64" after PEP 427 and 425)
>
>
> $ twine upload dist/llvmlite-0.1-py2.py3-none-linux_x86_64.whl
> Uploading distributions to https://pypi.python.org/pypi
> Uploading llvmlite-0.1-py2.py3-none-linux_x86_64.whl
> Traceback (most recent call last):
> File
> "/home/antoine/.local/lib/python3.4/site-packages/twine/commands/upload.py",
> line 228, in main
> upload(**vars(args))
> File
> "/home/antoine/.local/lib/python3.4/site-packages/twine/commands/upload.py",
> line 183, in upload
> resp.raise_for_status()
> File "/home/antoine/.local/lib/python3.4/site-packages/requests/models.py",
> line 825, in raise_for_status
> raise HTTPError(http_error_msg, response=self)
> requests.exceptions.HTTPError: 400 Client Error: Binary wheel for an
> unsupported platform
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "/home/antoine/.local/bin/twine-upload", line 11, in
> sys.exit(main())
> File
> "/home/antoine/.local/lib/python3.4/site-packages/twine/commands/upload.py",
> line 230, in main
> sys.exit("{0}: {1}".format(exc.__class__.__name__, exc.message))
> AttributeError: 'HTTPError' object has no attribute 'message'
>
>
> (also note the Python 3 buglet in main() above)
FYI, it looks like this has been fixed already:
https://github.com/pypa/twine/commit/162ab0e9d0d93a2357a6440bdf7af1835247e025
--Chris
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] "not a supported wheel on this platform"
On Tue, 28 Oct 2014 14:44:22 + Paul Moore wrote: > Can you see what the following says (results here are from my Windows > Python 3.4 system)? > > >>> from wheel.pep425tags import get_supported > >>> ['-'.join(t) for t in get_supported()] > ['cp34-none-win_amd64', 'cp34-none-any', 'cp3-none-any', > 'cp33-none-any', 'cp32-none-any', 'cp31-none-any', 'cp30-none-any', > 'py34-none-any', 'py3-none-any', 'py33-none-any', 'py32-none-any', > 'py31-none-any', 'py30-none-any'] > > I suspect you might be missing the combination "py2" with an > architecture other than "any". Does matching really happen that way? Here it is anyway. There's no "py2" at all: >>> ['-'.join(t) for t in get_supported()] ['cp34-cp34m-linux_x86_64', 'cp34-abi3-linux_x86_64', 'cp34-none-linux_x86_64', 'cp34-none-any', 'cp3-none-any', 'cp33-none-any', 'cp32-none-any', 'cp31-none-any', 'cp30-none-any', 'py34-none-any', 'py3-none-any', 'py33-none-any', 'py32-none-any', 'py31-none-any', 'py30-none-any'] Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] "not a supported wheel on this platform"
Can you see what the following says (results here are from my Windows
Python 3.4 system)?
>>> from wheel.pep425tags import get_supported
>>> ['-'.join(t) for t in get_supported()]
['cp34-none-win_amd64', 'cp34-none-any', 'cp3-none-any',
'cp33-none-any', 'cp32-none-any', 'cp31-none-any', 'cp30-none-any',
'py34-none-any', 'py3-none-any', 'py33-none-any', 'py32-none-any',
'py31-none-any', 'py30-none-any']
I suspect you might be missing the combination "py2" with an
architecture other than "any".
Paul
On 28 October 2014 14:22, Antoine Pitrou wrote:
>
> Hello,
>
> Ok, so until I find a better solution I've tried hosting a wheel on a
> personal server, but then I get the following error when installing it:
>
> $ pyvenv-3.4 t
> $ source t/bin/activate
> (t) $ pip install
> https://ssl.pitrou.net/llvmlite-0.1-py2.py3-none-linux_x86_64.whl
> llvmlite-0.1-py2.py3-none-linux_x86_64.whl is not a supported wheel on this
> platform.
> Storing debug log for failure in /home/antoine/.pip/pip.log
>
> Yet:
>
> (t) $ python
> Python 3.4.1 (3.4:d1bf37def4fd, May 19 2014, 19:52:53)
> [GCC 4.8.1] on linux
> Type "help", "copyright", "credits" or "license" for more information.
import sysconfig
sysconfig.get_platform()
> 'linux-x86_64'
>
>
> The log file doesn't tell anything really interesting:
>
>
> /home/antoine/t/t/bin/pip run on Tue Oct 28 15:18:06 2014
> llvmlite-0.1-py2.py3-none-linux_x86_64.whl is not a supported wheel on this
> platform.
> Exception information:
> Traceback (most recent call last):
> File "/home/antoine/t/t/lib/python3.4/site-packages/pip/basecommand.py",
> line 122, in main
> status = self.run(options, args)
> File
> "/home/antoine/t/t/lib/python3.4/site-packages/pip/commands/install.py", line
> 257, in run
> InstallRequirement.from_line(name, None))
> File "/home/antoine/t/t/lib/python3.4/site-packages/pip/req.py", line 167,
> in from_line
> raise UnsupportedWheel("%s is not a supported wheel on this platform." %
> wheel.filename)
> pip.exceptions.UnsupportedWheel: llvmlite-0.1-py2.py3-none-linux_x86_64.whl
> is not a supported wheel on this platform.
>
>
> Regards
>
> Antoine.
>
>
> ___
> Distutils-SIG maillist - Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] toml
On Tue, Oct 28, 2014 at 2:59 AM, holger krekel wrote: > On Mon, Oct 27, 2014 at 16:45 -0400, Daniel Holth wrote: >> I liked it because I agree with the TOML author that the YAML spec >> gives rage; YAML seems to be defined as a bunch of things that the end >> user is supposed to think are intuitive, but try understanding and >> correctly parsing the full set of what is allowed... TOML on the other >> hand is short. > > Don't know but TOML could work well as a user facing config syntax. > Seems to be reasonably well defined and more expressive than plain ini > files. Would be curious if it could be used for tox for example. Daniel, Holger, et al., what is wrong with ini out of curiosity? Thanks, --Chris ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] "not a supported wheel on this platform"
Hello,
Ok, so until I find a better solution I've tried hosting a wheel on a
personal server, but then I get the following error when installing it:
$ pyvenv-3.4 t
$ source t/bin/activate
(t) $ pip install
https://ssl.pitrou.net/llvmlite-0.1-py2.py3-none-linux_x86_64.whl
llvmlite-0.1-py2.py3-none-linux_x86_64.whl is not a supported wheel on this
platform.
Storing debug log for failure in /home/antoine/.pip/pip.log
Yet:
(t) $ python
Python 3.4.1 (3.4:d1bf37def4fd, May 19 2014, 19:52:53)
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> sysconfig.get_platform()
'linux-x86_64'
The log file doesn't tell anything really interesting:
/home/antoine/t/t/bin/pip run on Tue Oct 28 15:18:06 2014
llvmlite-0.1-py2.py3-none-linux_x86_64.whl is not a supported wheel on this
platform.
Exception information:
Traceback (most recent call last):
File "/home/antoine/t/t/lib/python3.4/site-packages/pip/basecommand.py", line
122, in main
status = self.run(options, args)
File "/home/antoine/t/t/lib/python3.4/site-packages/pip/commands/install.py",
line 257, in run
InstallRequirement.from_line(name, None))
File "/home/antoine/t/t/lib/python3.4/site-packages/pip/req.py", line 167, in
from_line
raise UnsupportedWheel("%s is not a supported wheel on this platform." %
wheel.filename)
pip.exceptions.UnsupportedWheel: llvmlite-0.1-py2.py3-none-linux_x86_64.whl is
not a supported wheel on this platform.
Regards
Antoine.
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Making a wheel platform-specific?
>> Paul forgot an important word there, *verified* HTTPS. Paul always forgets the important details when discussing security :-) Sorry. Paul. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] twine: Binary wheel for an unsupported platform
On 28 October 2014 14:04, Antoine Pitrou wrote: > I guess I am doing something wrong, but what? > (I took "linux_x86_64" after PEP 427 and 425) Oops, I mentioned this in another thread but forgot it when responding to you. Sorry. PyPI does not currently allow uploading binary wheels for Linux, because the "compatibility tags" issues are unresolved, and the decision was taken to block binary uploads rather than cause user confusion when pip started installing unusable binaries. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Making a wheel platform-specific?
On Tue, 28 Oct 2014 10:04:17 -0400 Donald Stufft wrote: > > > On Oct 28, 2014, at 9:43 AM, Antoine Pitrou wrote: > > > >> I think twine can do that for you (and is generally recommended these > >> days over setup.py upload, as it uses https). > > > > setup.py upload also uses https these days, AFAIK. > > Paul forgot an important word there, *verified* HTTPS. Yes, you're right. Thanks for doing this. Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP425 - Wheel Binary Package Compatibility
On 28 October 2014 10:13, Matthias Hafner wrote: (in reverse order, easiest to hardest :-)) > Why does that work on MacOS, btw? Are all library versions fixed there for > one version of OSX? I believe (I'm not 100% sure as I'm a Windows user not an OSX user) that PyPI only supports binaries compatible with the official python.org binaries of Python. So library version decisions are moot. This means that homebrew or "the other ones" (sorry :-)) users can't avail themselves of PyPI-hosted binaries yet, until the wider library compatibility issues are resolved. > So should the wheel be shipped with GLIBC, or the GLIBC version be specified > in the wheel name (means to build a new wheel for each GLIBC version?). > Also, maybe this is not the only library it is dynamically linked against? Whatever solution is devised will need to be encapsulated in a set of compatibility tags (see PEP 425) that capture what it means to be "compatible". The wheels can then be uploaded with the correct tags, and pip and other tools will automatically select the right one (or report an error if no suitable binary exists and source is not available). > How should we deal with incompatibility of dynamically linked libraries? > Doing "pip wheel numpy" on a Linux 64bit machine results in , which is > linked dynamically against the GLIBC version installed on the build machine. This is the big question. On Windows, we only really have to deal with 32-bit or 64-bit binaries, using the C runtime that the python.org binaries use. So the architecture is sufficient and the ABI flag is unused. On OSX, as I say, PyPI has in effect artificially set up a similar situation, by not considering anything other than python.org build compatible binaries. On Linux, nobody has really looked at the problem (beyond acknowledging that it exists). We need a group of Linux experts with an understanding of how all the various aspects of distribution, kernel, libc, etc, work together to form a "compatible environment" for binaries. As Linux has a strong culture of only building from source or using distro packages, there doesn't seem to me (as an outsider) to be much momentum around solving this. Sorry I can't offer any more help or clarification than this. Hopefully someone from the Linux side of things can offer some views on how this can be moved forwards. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] twine: Binary wheel for an unsupported platform
Hello,
I guess I am doing something wrong, but what?
(I took "linux_x86_64" after PEP 427 and 425)
$ twine upload dist/llvmlite-0.1-py2.py3-none-linux_x86_64.whl
Uploading distributions to https://pypi.python.org/pypi
Uploading llvmlite-0.1-py2.py3-none-linux_x86_64.whl
Traceback (most recent call last):
File
"/home/antoine/.local/lib/python3.4/site-packages/twine/commands/upload.py",
line 228, in main
upload(**vars(args))
File
"/home/antoine/.local/lib/python3.4/site-packages/twine/commands/upload.py",
line 183, in upload
resp.raise_for_status()
File "/home/antoine/.local/lib/python3.4/site-packages/requests/models.py",
line 825, in raise_for_status
raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 400 Client Error: Binary wheel for an
unsupported platform
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/antoine/.local/bin/twine-upload", line 11, in
sys.exit(main())
File
"/home/antoine/.local/lib/python3.4/site-packages/twine/commands/upload.py",
line 230, in main
sys.exit("{0}: {1}".format(exc.__class__.__name__, exc.message))
AttributeError: 'HTTPError' object has no attribute 'message'
(also note the Python 3 buglet in main() above)
Regards
Antoine.
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Making a wheel platform-specific?
> On Oct 28, 2014, at 9:43 AM, Antoine Pitrou wrote: > >> I think twine can do that for you (and is generally recommended these >> days over setup.py upload, as it uses https). > > setup.py upload also uses https these days, AFAIK. Paul forgot an important word there, *verified* HTTPS. It is true that recently Python switched the default from http:// to https:// however in any released version of Python it still does not *verify* that when uploading. I believe that PEP 476 will change that but it’s not in any released Python to my knowledge and even then it’s hard to tell people “Well setup.py upload is safe, in these particular scenarios” when it’s hard to declare exactly when those scenarios are (Python versions, but also some older versions thanks to downstream back porting patches etc). It doesn’t help either that the design of distutils doesn’t allow uploading an existing file so if you, for instance, want to upload a Python 2.6 specific Wheel then that won’t have PEP 476 and then something like twine is the only way forward. All in all it’s easier to just say “don’t use that, use this instead” than to explain when and why it’s ok to use that. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Making a wheel platform-specific?
On Tue, 28 Oct 2014 13:39:32 + Paul Moore wrote: > On 28 October 2014 13:20, Antoine Pitrou wrote: > > If I rename the file manually, is there an easy (CLI-based) way of > > uploading it to PyPI? > > I think twine can do that for you (and is generally recommended these > days over setup.py upload, as it uses https). setup.py upload also uses https these days, AFAIK. But I'll take a look at twine (*sigh*... another tool). Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] toml
There's also AXON ("It tries to combine the best of JSON, XML and
YAML.") – http://intellimath.bitbucket.org/axon/
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] PEP425 - Wheel Binary Package Compatibility
Hi there, Following up on https://bitbucket.org/pypa/wheel/issue/124/glibc-incompatibility. How should we deal with incompatibility of dynamically linked libraries? Doing "pip wheel numpy" on a Linux 64bit machine results in , which is linked dynamically against the GLIBC version installed on the build machine. So should the wheel be shipped with GLIBC, or the GLIBC version be specified in the wheel name (means to build a new wheel for each GLIBC version?). Also, maybe this is not the only library it is dynamically linked against? Why does that work on MacOS, btw? Are all library versions fixed there for one version of OSX? Thanks for putting some light into this issue. Best regards, Matthias ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Making a wheel platform-specific?
On 28 October 2014 13:20, Antoine Pitrou wrote: > If I rename the file manually, is there an easy (CLI-based) way of > uploading it to PyPI? I think twine can do that for you (and is generally recommended these days over setup.py upload, as it uses https). > Also, there's a remaining issue: how do I tell wheel that the package > needs platlib rather than purelib? > (may that question also apply to other bdist* flavours?) You're right that's probably a more general question. For wheels, there's a "Root-Is-Purelib" entry in the WHEEL file in the metadata. That one would need manual hacking, unfortunately. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Making a wheel platform-specific?
2014-10-28 14:20 GMT+01:00 Antoine Pitrou : > > If I rename the file manually, is there an easy (CLI-based) way of > uploading it to PyPI? I had the same issue for a tool that collects wheels generated by various CI platforms to prepare a binary release. https://github.com/ogrisel/wheelhouse-uploader Here is the hack I did (a distutils command extension): https://github.com/ogrisel/wheelhouse-uploader/blob/master/wheelhouse_uploader/cmd.py#L54 -- Olivier http://twitter.com/ogrisel - http://github.com/ogrisel ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Making a wheel platform-specific?
On Tue, 28 Oct 2014 13:15:09 + Paul Moore wrote: > On 28 October 2014 12:57, Antoine Pitrou wrote: > > I would like to tell bdist_wheel to therefore tag the package as a > > Python-independent, platform-dependent binary package. There doesn't > > seem to be a way of doing so, or is there? > > I don't believe there is at the moment. But the tags are *only* > recorded in the filename, so it's perfectly OK to simply rename the > wheel file manually after it's created. > > It would be nice to file a feature request for this on the wheel > tracker (https://bitbucket.org/pypa/wheel) as well, if there's nothing > there already, so we don't forget. Ok, the issue already existed: https://bitbucket.org/pypa/wheel/issue/100/binary-wheels-for-different-python Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Making a wheel platform-specific?
On Tue, 28 Oct 2014 13:15:09 + Paul Moore wrote: > On 28 October 2014 12:57, Antoine Pitrou wrote: > > I would like to tell bdist_wheel to therefore tag the package as a > > Python-independent, platform-dependent binary package. There doesn't > > seem to be a way of doing so, or is there? > > I don't believe there is at the moment. But the tags are *only* > recorded in the filename, so it's perfectly OK to simply rename the > wheel file manually after it's created. > > It would be nice to file a feature request for this on the wheel > tracker (https://bitbucket.org/pypa/wheel) as well, if there's nothing > there already, so we don't forget. Ok, will do. I was assuming the compatibility tags would be recorded somewhere in the metadata. If I rename the file manually, is there an easy (CLI-based) way of uploading it to PyPI? Also, there's a remaining issue: how do I tell wheel that the package needs platlib rather than purelib? (may that question also apply to other bdist* flavours?) Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Making a wheel platform-specific?
On 28 October 2014 12:57, Antoine Pitrou wrote: > I would like to tell bdist_wheel to therefore tag the package as a > Python-independent, platform-dependent binary package. There doesn't > seem to be a way of doing so, or is there? I don't believe there is at the moment. But the tags are *only* recorded in the filename, so it's perfectly OK to simply rename the wheel file manually after it's created. It would be nice to file a feature request for this on the wheel tracker (https://bitbucket.org/pypa/wheel) as well, if there's nothing there already, so we don't forget. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Making a wheel platform-specific?
Hello, I am trying to package a project which has the following features: - pure Python code (2- and 3-compatible) - no C extensions (therefore no CPython ABI issues) - but there's a .so file (or DLL) that's loaded at runtime using ctypes (FYI: https://github.com/numba/llvmlite) I would like to tell bdist_wheel to therefore tag the package as a Python-independent, platform-dependent binary package. There doesn't seem to be a way of doing so, or is there? Regards Antoine. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] toml
On Mon, Oct 27, 2014 at 16:45 -0400, Daniel Holth wrote: > I liked it because I agree with the TOML author that the YAML spec > gives rage; YAML seems to be defined as a bunch of things that the end > user is supposed to think are intuitive, but try understanding and > correctly parsing the full set of what is allowed... TOML on the other > hand is short. Don't know but TOML could work well as a user facing config syntax. Seems to be reasonably well defined and more expressive than plain ini files. Would be curious if it could be used for tox for example. cheers, holger > On Mon, Oct 27, 2014 at 4:23 PM, Paul Moore wrote: > > On 27 October 2014 19:23, Donald Stufft wrote: > >> Ugh, I hate TOML. I’m -1 on any of the standards using it, but I also > >> think the standards should be around data exchange and should just use > >> JSON and leave front end stuff like that up to the implementations. > > > > I had a quick glance at TOML, and I can't say I was particularly > > enamoured by it. I don't see that it has any particularly huge > > benefits over "plain" ini files (if your needs are simple) or YAML > > (ignoring the over-complicated stuff that nobody actually needs). > > > > +1 on JSON for "internal" format, and tools deciding for themselves on > > the best user-facing format. > > > > I'm also not sure I see the value of mapping directly to a dict. > > Surely internal formats should be isolated from the user interface, > > not exposed directly? > > Paul > ___ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
