[Distutils] Re: manylinux1 guidelines for zlib?

Updating on this. It seems the manylinux1 tooling may automatically link and bundle an old zlib version if you link dynamically against it. That can be counter-productive... Regards Antoine. -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to

[Distutils] Re: Opinions on requiring younger glibc in manylinux1 wheel?

Nathaniel Smith wrote: > It's naughty, you shouldn't do it, and the energy you put into making > pseudo-manylinux1 wheels could probably be better put into making finishing > up the manylinux2010 work – there's not that much to do. Can you explain what's missing? Paul Moore wrote: > 1. It sounds

[Distutils] Re: Opinions on requiring younger glibc in manylinux1 wheel?

Paul Moore wrote: > I'm not really familiar with manylinux1, but I'd be concerned if we > started getting bug reports on pip because we installed a library that > claimed to be manylinux1 and was failing because it wasn't. (And yes, > packaging errors like this are a common source of pip bug

[Distutils] Re: Opinions on requiring younger glibc in manylinux1 wheel?

Trishank Kuppusamy wrote: > We are looking for help to review manylinux2010, though: Yes, but I'm not competent for that unfortunately. Sorry :-( Regards Antoine. -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org

[Distutils] Re: Opinions on requiring younger glibc in manylinux1 wheel?

Trishank Kuppusamy wrote: > I think this will require updating the PEP, at the very least: Sorry, there was a misunderstanding. Maybe I should have been clearer. My question was about publishing deliberately incompatible manylinux1 wheels (without changing the PEP). Regards Antoine. --

[Distutils] Opinions on requiring younger glibc in manylinux1 wheel?

Hi, According to recent messages, it seems manylinux2010 won't be ready soon. However, the baseline software in manylinux1 is becoming very old. As an example, a popular C++ library (Abseil - https://abseil.io/) requires a more recent glibc (see

[Distutils] manylinux1 guidelines for zlib?

Hello, Surprisingly, the manylinux1 spec doesn't seem to include the zlib in the list of known-to-be-available libraries (are there GNU/Linux systems out there without a zlib installed?). Since I'm assuming several packages already had a need for that, is there a recommended way to link in

Re: [Distutils] What is the official position on distutils?

On Tue, 30 Aug 2016 14:44:10 +0100 Paul Moore <p.f.mo...@gmail.com> wrote: > On 30 August 2016 at 13:38, Antoine Pitrou <solip...@pitrou.net> wrote: > > On Tue, 30 Aug 2016 13:34:22 +0100 > > Paul Moore <p.f.mo...@gmail.com> wrote: > >> > >&g

Re: [Distutils] What is the official position on distutils?

On Tue, 30 Aug 2016 13:34:22 +0100 Paul Moore wrote: > > From what I know, anyone who is actually hacking into the internal > APIs to that level tends to use only distutils (probably because as > you say, setuptools is even worse) and therefore falls into my > category of

Re: [Distutils] PEP 527 - Removing Un(der)used file types/extensions on PyPI

On Thu, 25 Aug 2016 17:46:03 +0200 "M.-A. Lemburg" wrote: > +sources of truth for a single version. Having multiple sdists often > times can > +account for strange bugs that only expose themselves based on which > sdist that > +the person used. > > You may not be aware, but

Re: [Distutils] Deprecating little used file types/extensions on PyPI?

On Tue, 23 Aug 2016 10:36:35 +0100 Paul Moore wrote: > > I don't see any sign of *anyone* working on a curated distribution for > Windows along the lines of Linux distros or Homebrew. (Unless you > count cross-platform stacks like conda, which IMO are a different > scenario

[Distutils] setuptools 25.1.6 broke numpy.distutils on Windows

Hello, Just a heads-up that latest setuptools is incompatible with numpy.distutils on Windows: https://github.com/pypa/setuptools/issues/728 The whole scientific community will suffer until this issue is solved one way or the other (either on the setuptools side, or on the Numpy side, or both).

Re: [Distutils] PEP for specifying build dependencies

On Wed, 11 May 2016 18:32:30 + Brett Cannon wrote: > > > > The only open issue in the PEP at the moment is the bikeshedding topic of > > what to name the sub-section containing the requirements: `[package.build]` > > or `[package.build-system]` (we couldn't reach consensus

Re: [Distutils] PEP for specifying build dependencies

On Thu, 12 May 2016 00:20:32 +1000 Nick Coghlan wrote: > > When I say "build system configuration" in the context of > distutils/setuptools, I mean things like: > > * MANIFEST.in > * non-dependency related setup() arguments (packages, package_dir, > py_modules, ext_modules,

Re: [Distutils] comparison of configuration languages

On Tue, 10 May 2016 10:55:38 -0400 Donald Stufft wrote: > > I think TOML is more usable than ConfigParser and in particular I think that > the adhoc post processing step makes ConfigParser inherently less usable > because it forces a special syntax that is specific to this one

Re: [Distutils] comparison of configuration languages

On Tue, 10 May 2016 10:24:10 -0400 Donald Stufft wrote: > > TOML is infinitely better at nested structured that ConfigParser, given that > TOML actually *supports* nested structures beyond a level of 1. The only way > to get anything like: > > [package.build] >

Re: [Distutils] comparison of configuration languages

On Tue, 10 May 2016 10:38:51 +0300 Alex Grönholm wrote: > TOML isn't much better than ConfigParser in terms of representing nested > structures. Indeed, that seems to be a strong point against TOML. If we don't care about nested structures that much, then ConfigParser

Re: [Distutils] For maximum performance, Python packages are best installed as zip files.

On Mon, 11 Apr 2016 07:40:05 -0400 Donald Stufft <don...@stufft.io> wrote: > > > On Apr 11, 2016, at 7:36 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > > > > There is a certain number of disk accesses > > that is necessary to get the required metadata

Re: [Distutils] For maximum performance, Python packages are best installed as zip files.

On Mon, 11 Apr 2016 07:33:05 -0400 Donald Stufft <don...@stufft.io> wrote: > > > On Apr 11, 2016, at 7:23 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > > > > On Mon, 11 Apr 2016 07:08:19 -0400 > > Donald Stufft <don...@stufft.io> wrote: >

Re: [Distutils] abstract build system approaches redux

On Thu, 3 Mar 2016 08:44:56 -0500 Donald Stufft wrote: > > I'd like to push back against this, speaking as someone who was originally pro > CLI: > > I think that a Python API is actually better for one reason: introspection. > I cannot think of a particularly great way to have

Re: [Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

On Wed, 17 Feb 2016 05:12:48 -0500 "Eric V. Smith" <e...@trueblade.com> wrote: > On 2/17/2016 3:55 AM, Antoine Pitrou wrote: > > On Tue, 16 Feb 2016 16:10:34 -0800 > > Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: > >> > >> I am 100% on

Re: [Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

On Tue, 16 Feb 2016 16:10:34 -0800 Glyph Lefkowitz wrote: > > I am 100% on board with telling people "don't use `sudo pip install´". > Frankly I have been telling the pip developers to just break this for years > (see https://pip2014.com, which, much to my chagrin,

Re: [Distutils] Does anyone understand what's going on with libpython on Linux?

On Sun, 7 Feb 2016 00:25:57 -0800 "Robert T. McGibbon" wrote: > > What are Debian/Ubuntu doing in distutils so that extensions don't link > to libpython by default? > > I don't know exactly, but one way to reproduce this is simply to build the > interpreter without

Re: [Distutils] Status update on the NumPy & SciPy vs SSE problem?

On Fri, 5 Feb 2016 21:46:54 +1000 Nick Coghlan wrote: > > Thanks for the replies, folks! > > Checking I've understood the respective updates correctly: > > - x86_64 implies SSE2 capability > - most i686 machines still in use are also SSE2 capable > - Accelerate provides

Re: [Distutils] Status update on the NumPy & SciPy vs SSE problem?

On Thu, 4 Feb 2016 21:22:32 +1000 Nick Coghlan wrote: > > I figured that was independent of the manylinux PEP (since it affects > Windows as well), but I'm also curious as to the current status (I > found a couple of apparently relevant threads on the NumPy list, but >

Re: [Distutils] draft PEP: manylinux1

On Tue, 26 Jan 2016 06:50:15 -0500 Alexander Walters wrote: > Isnt the entire point of using centos 5 to use an ancient toolchain? No, the point is to link against an ancient glibc. The toolchain can be modern (and actually has to if you want to compile e.g. C++11 code).

Re: [Distutils] draft PEP: manylinux1

On Tue, 26 Jan 2016 20:36:26 +1000 Nick Coghlan wrote: > > If I understand the problem correctly, the CentOS 5 gcc toolchain is > old enough that it simply doesn't emit the info libabigail needs in > order to work. If you build on CentOS 5, you certainly want to use the RH

Re: [Distutils] Non English Speaking Users of PyPI - I need Help!

On Tue, 26 Jan 2016 12:16:16 -0500 Donald Stufft wrote: > > As many of you are aware there has been an effort to replace the current PyPI > with a new, improved PyPI. This project has been codenamed Warehouse and has > been progressing nicely. However we’ve run into a bit of

Re: [Distutils] Non English Speaking Users of PyPI - I need Help!

On Tue, 26 Jan 2016 14:10:28 -0500 Donald Stufft wrote: > > Hopefully this was useful information! It was certainly comprehensive. Thank you :-) About gettext's shortcomings... I think it's so widely used that it's probably possible to work around them whenever they appear.

Re: [Distutils] draft PEP: manylinux1

On Thu, 21 Jan 2016 11:42:57 -0800 Chris Barker wrote: > nice, idea, but > > libX11.so.6 > libXext.so.6 > libXrender.so.1 > libGL.so.1 > > These are all X11, yes? pretty much any workstation will have these, but in > general, servers won't. For the

Re: [Distutils] New Design Landed in Warehouse

On Sat, 21 Nov 2015 08:46:45 +0100 Antoine Pitrou <solip...@pitrou.net> wrote: > > Agreed. The look of the average project page is a bit depressing: > https://warehouse.python.org/project/six/ > > Useful content starts only 2/3 down the first page. The large "pip >

Re: [Distutils] New Design Landed in Warehouse

On Fri, 20 Nov 2015 11:40:23 -0500 Randy Syring wrote: > I'm glad to see progress being made. Thanks for the time and effort > that is being put into this. > > After taking a look, the one thing that really stuck out to me in a > negative way was how much screen

Re: [Distutils] build system abstraction PEP, take #2

On Tue, 17 Nov 2015 09:33:56 -0500 Donald Stufft <don...@stufft.io> wrote: > > > On Nov 17, 2015, at 9:27 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > > > >> > >> There are a number of separate subcommands that build systems must support. > &

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

On Tue, 17 Nov 2015 09:46:21 +1300 Robert Collins wrote: > > URI_reference = > URI = scheme ':' hier_part ('?' query )? ( '#' fragment)? > hier_part = ('//' authority path_abempty) | path_absolute | > path_rootless | path_empty >

Re: [Distutils] Pip is not a library was: FINAL DRAFT: Dependency specifier PEP

On Tue, 17 Nov 2015 03:33:09 -0800 Nathaniel Smith wrote: > > Presumably there will be a dependency parser added to the 'packaging' > library, which already exists as a standard place to stick stuff like this, > so you'll just use that. (E.g. it's what pip uses for PEP 440

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

On Wed, 18 Nov 2015 06:32:35 +1300 Robert Collins wrote: > > > > The only place where URIs are used seem to be the "urlspec" rule, and > > probably you can accept any opaque string there. > > Uhm, why are you making this suggestion? What problem will we solve by >

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

On Wed, 18 Nov 2015 06:47:53 +1300 Robert Collins wrote: > Note that previous PEPs have either had no grammar (and > interop issue) or partially defined grammar's (and logical issues - > see PEP-426 for example). I think its very important we be able to > test what

Re: [Distutils] The future of invoking pip

On Mon, 9 Nov 2015 12:01:37 + Paul Moore wrote: > > The one thing that *is* special about pip is that it actually > *modifies* the Python installation it runs under. Fortunately, though, if you are running the system pip without having root privileges activated, it will

Re: [Distutils] The future of invoking pip

On Mon, 9 Nov 2015 11:16:56 + Oscar Benjamin wrote: > On 9 November 2015 at 10:44, Wolfgang Maier > wrote: > > > > Something I miss in all the discussions taking place here is the fact that > > python -m pip is the

Re: [Distutils] The future of invoking pip

On Sat, 7 Nov 2015 19:37:03 -0500 Donald Stufft wrote: > In fact, the pyvenv script has been deprecated and is going to be > removed in Python 3.8 in favor of `python -m venv` for similar > reasons that I've described here. That's not an argument, since the decision was taken

Re: [Distutils] The future of invoking pip

The actual question is: which problem are you trying to solve *that current users are actually experiencing*? I'm -1 on removing the "pip" command. "python -m pip" is frankly not a reasonable subtitution if we want to *promote* pip. > * The above gets *really* confusing when ``pipX`` or

Re: [Distutils] The future of invoking pip

On Sat, 7 Nov 2015 19:16:55 -0500 Donald Stufft wrote: > > The largest problem comes when ``python`` and ``pip`` disagree about which > Python is being invoked. As a said, this is a problem for package managers and distributions. "pip" isn't the only affected command, e.g.

Re: [Distutils] The future of invoking pip

On Sat, 7 Nov 2015 23:41:25 + Paul Moore <p.f.mo...@gmail.com> wrote: > On 7 November 2015 at 22:21, Antoine Pitrou <solip...@pitrou.net> wrote: > > The actual question is: which problem are you trying to solve *that > > current users are actually experiencing*? &

Re: [Distutils] Undelying design is fundamentally difficult to extend was: Remove distutils, was: red, green, refactor ...

On Thu, 22 Oct 2015 18:15:37 +0200 Thomas Güttler wrote: > > > On top of this, the goal of lots of efforts around packaging is to allow > > people to move away from distutils/setuptools, as the underlying design is > > fundamentally difficult to extend. > > If

Re: [Distutils] Time for a setuptools_lite??

On Wed, 21 Oct 2015 21:41:35 +0100 Paul Moore wrote: > On 21 October 2015 at 20:41, Chris Barker wrote: > > As I understand it, the current "API" that pip knows about is: > > > > "some subset of what setuptools provides" > > > > So my proposal is here

Re: [Distutils] Time for a setuptools_lite??

On Wed, 21 Oct 2015 18:29:17 + Daniel Holth wrote: > We're not just grumpy, we have seen The One Build System idea tried several > times with bad results. Instead, if you have the inclination, time, and > ability, you could try to build a new competing build system like >

Re: [Distutils] Remove distutils, was: red, green, refactor ...

On Wed, 21 Oct 2015 15:30:51 +0300 Ionel Cristian Mărieș <cont...@ionelmc.ro> wrote: > On Wed, Oct 21, 2015 at 3:10 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > > > (3) because distutils is part of the standard library and setuptools is > > most likely unwe

Re: [Distutils] warning about potential problem for wheels

On Wed, 14 Oct 2015 09:25:43 -0700 Chris Barker <chris.bar...@noaa.gov> wrote: > On Wed, Oct 14, 2015 at 3:40 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > > > On Tue, 13 Oct 2015 09:59:05 -0700 > > Chris Barker <chris.bar...@noaa.gov> wrote: > &g

Re: [Distutils] warning about potential problem for wheels

On Tue, 13 Oct 2015 09:59:05 -0700 Chris Barker wrote: > > So even is SSE2 provides little for Python itself, in the usual case, we'll > see performance hits n compiled extensions that are not compiled by > particularly smart people. Since the question is only for 32-bit

Re: [Distutils] warning about potential problem for wheels

On Sun, 11 Oct 2015 08:07:30 -0700 Steve Dower wrote: > > This does only affect 32-bit builds, so now I'm thinking about the > possibility of treating those as highly compatible while the 64-bit > ones get better performance treatment, though I'm not sure how that > could

Re: [Distutils] sampleproject: use tox?

On Thu, 8 Oct 2015 22:05:16 +0200 Thomas Güttler wrote: > This is a follow up to the thread "Where should I put tests when packaging > python modules?" > > I have never used tox up to now. But reading the mails of the thread, it seems > that tox is the current

Re: [Distutils] Where should I put tests when packaging python modules?

On Tue, 6 Oct 2015 09:33:03 -0400 Donald Stufft <don...@stufft.io> wrote: > On October 6, 2015 at 9:08:12 AM, Antoine Pitrou (solip...@pitrou.net) wrote: > > On Tue, 6 Oct 2015 08:57:12 -0400 > > Donald Stufft wrote: > > > > > > It doesn't really make exper

Re: [Distutils] Where should I put tests when packaging python modules?

On Wed, 7 Oct 2015 00:47:31 +0300 Ionel Cristian Mărieș wrote: > On Tue, Oct 6, 2015 at 11:54 PM, Erik Bray wrote: > > > Skimming back through the rest of the thread I don't see too much > > support for 1). The only argument against it is the need for

Re: [Distutils] Where should I put tests when packaging python modules?

On Tue, 6 Oct 2015 16:16:41 -0600 Carl Meyer <c...@oddbird.net> wrote: > On 10/06/2015 04:04 PM, Antoine Pitrou wrote: > [snip] > > ...How are tests supposed to be a problem here, while they > > usually have so few dependencies of their own? > > > >> If you

Re: [Distutils] Where should I put tests when packaging python modules?

On Tue, 6 Oct 2015 09:07:46 +0200 Thomas Güttler wrote: > > Dear experts, please decide: > > inside the module like this answer: > > > http://stackoverflow.com/questions/5341006/where-should-i-put-tests-when-packaging-python-modules They should be inside the

Re: [Distutils] Where should I put tests when packaging python modules?

On Tue, 6 Oct 2015 09:17:22 +0100 Paul Moore <p.f.mo...@gmail.com> wrote: > On 6 October 2015 at 08:51, Antoine Pitrou <solip...@pitrou.net> wrote: > > They should be inside the module. That way, you can check an installed > > module is ok by running e.g. "pytho

Re: [Distutils] Where should I put tests when packaging python modules?

On Wed, 7 Oct 2015 01:44:34 +0300 Ionel Cristian Mărieș wrote: > > That leaves me with 22 packages that need test tools like pytest/nose and > assorted plugins. > [...] > > ​It's double the trouble to find compatible releases. Hmm, are you saying py.test / nose and

Re: [Distutils] Where should I put tests when packaging python modules?

On Tue, 6 Oct 2015 11:30:00 +0300 Ionel Cristian Mărieș <cont...@ionelmc.ro> wrote: > On Tue, Oct 6, 2015 at 10:51 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > > > They should be inside the module. That way, you can check an installed > > module is

Re: [Distutils] Where should I put tests when packaging python modules?

On Tue, 6 Oct 2015 08:57:12 -0400 Donald Stufft wrote: > > It doesn't really make experimenting in a VCS any harder, since all you need > to > do first is run ``pip install -e .`` and it will do a development install and > add the src/ directory to sys.path. That means you're

Re: [Distutils] Where should I put tests when packaging python modules?

On Tue, 6 Oct 2015 07:07:31 -0400 Donald Stufft wrote: > > I've never, in my entire life [...] Can I suggest your entire life is an anecdotal data point here? > This is still ignoring the problems of test dependencies Only if your tests have dependencies that runtime doesn't

Re: [Distutils] Where should I put tests when packaging python modules?

On Tue, 6 Oct 2015 15:34:38 +0300 Ionel Cristian Mărieș wrote: > > Very few > test runners change the current working directory by default [1], so it's > better to just get a better project layout. pyca/cryptography > is a good example.​

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Mon, 5 Oct 2015 08:44:04 -0400 Donald Stufft wrote: > > I don't think that it makes sense for pip to go directly from a VCS[1] to a > Wheel in the grand scheme of things. Right now we kind of do it, but that's > because we just treat them like an unpacked sdist [2], long

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Mon, 5 Oct 2015 14:11:56 +0100 Paul Moore wrote: > > Being a Windows user, I hadn't caught the parallel between > Wheel-Source wheel and RPM-Source RPM (is there also a similar > deb-source deb pair?) > > But if the concept works for people with a Linux background, I'm

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Mon, 5 Oct 2015 09:28:48 -0400 Donald Stufft wrote: > > > > In any case, sdists being apt for human consumption is an important > > feature IMHO. > > > > I don't think so. Remember in my footnote I mentioned that I wasn't using VCS > to mean literally "something checked

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On Mon, 5 Oct 2015 09:51:05 -0400 Donald Stufft wrote: > > You can see these needs are different I think by looking at how what > Nathaniel wants differs from what me and Paul want. He wants something that > will make the human side easier and will support different tools, we

[Distutils] Bogus search result

Hello, I don't if that's just me, but I go to https://pypi.python.org/pypi and type "llvmlite" into the search box, clicking the "search" button leads me to the page for the Numba package. It should either lead me to the page for the *llvmlite* package or show me a list of search results.

Re: [Distutils] Working toward Linux wheel support

On Thu, 20 Aug 2015 15:40:57 -0400 Nate Coraor n...@bx.psu.edu wrote: In practice, the `platform` module does not really keep up to date with evolution in the universe of Linux distributions. Understandable, although so far it's doing a pretty good job: Hmm, perhaps that one just

Re: [Distutils] Working toward Linux wheel support

On Fri, 17 Jul 2015 08:36:39 -0700 Chris Barker chris.bar...@noaa.gov wrote: - Packages with non-standard non-python dependencies: libhdf5, lapack, BLAS, fortran(!) -- this is where the nightmare really is. I suspect most folks on this list will say that this is Scipy Problem, and indeed,

Re: [Distutils] 400 Client Error: Binary wheel for an unsupported platform

On Thu, 9 Jul 2015 17:52:06 +0100 David Cournapeau courn...@gmail.com wrote: I don't think it is reasonable for pypa to recommend one solution when multiple are available (though it is certainly fair to mention them). ActiveState, Enthought (my own employer) also provide linux binaries, You

Re: [Distutils] 400 Client Error: Binary wheel for an unsupported platform

On Thu, 9 Jul 2015 23:50:30 +1000 Nick Coghlan ncogh...@gmail.com wrote: As Donald notes, I think we're now in a good position to start making progress here, but the first step is going to be finding a way to ensure that *by default*, pip on Linux ignores wheel files published on PyPI, and

Re: [Distutils] 400 Client Error: Binary wheel for an unsupported platform

On Wed, 08 Jul 2015 05:39:13 -0400 Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/2015 07:43 PM, Antoine Pitrou wrote: That's a dramatically uninformed statement, to put it politely... Some packages have difficult-to-meet build

Re: [Distutils] 400 Client Error: Binary wheel for an unsupported platform

On Wed, 08 Jul 2015 13:05:45 -0400 Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/2015 07:10 AM, Antoine Pitrou wrote: Seriously, how this is even supposed to be relevant? The whole point is to produce best-effort packages that work

Re: [Distutils] 400 Client Error: Binary wheel for an unsupported platform

On Tue, 7 Jul 2015 11:02:40 -0400 Donald Stufft don...@stufft.io wrote: In my mind, the biggest reason to not just open up the ability to upload even generic linux wheels right now is the lack of a safe-ish default. I think if we added a few things: * Default to per platform tags (e.g.

Re: [Distutils] 400 Client Error: Binary wheel for an unsupported platform

On Tue, 7 Jul 2015 23:53:59 +1000 Nick Coghlan ncogh...@gmail.com wrote: On 7 July 2015 at 07:46, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 6 Jul 2015 22:34:38 +0100 Paul Moore p.f.mo...@gmail.com wrote: On 6 July 2015 at 19:18, Antoine Pitrou solip...@pitrou.net wrote: What

[Distutils] 400 Client Error: Binary wheel for an unsupported platform

Hello, I'm having the following errors when trying to upload a wheel to PyPI. (yes, the version number is off - but that's besides the point here, I think): $ twine upload dist/llvmlite-0.0.0-py2.py3-none-linux_x86_64.whl

Re: [Distutils] 400 Client Error: Binary wheel for an unsupported platform

On Mon, 6 Jul 2015 19:03:19 +0100 Paul Moore p.f.mo...@gmail.com wrote: On 6 July 2015 at 17:24, Antoine Pitrou solip...@pitrou.net wrote: (yes, the version number is off - but that's besides the point here, I think): $ twine upload dist/llvmlite-0.0.0-py2.py3-none-linux_x86_64.whl

Re: [Distutils] 400 Client Error: Binary wheel for an unsupported platform

On Mon, 6 Jul 2015 22:34:38 +0100 Paul Moore p.f.mo...@gmail.com wrote: On 6 July 2015 at 19:18, Antoine Pitrou solip...@pitrou.net wrote: What if packagers take care of working around the issue? (for example by building on a suitably old Linux platform, as we already do for Conda packages

[Distutils] PyPI search engine slow

Hello, It seems that PyPI's search engine has become quite slow. For example the following URL takes ~8s. to load: https://pypi.python.org/pypi?%3Aaction=searchterm=signature%20inspectsubmit=search Regards Antoine. ___ Distutils-SIG maillist -

Re: [Distutils] Role of setuptools and eggs in modern distributing...

On Tue, 23 Dec 2014 09:36:36 -0800 Chris Barker chris.bar...@noaa.gov wrote: So far, we've been doing mostly pip and struggling with build our own for the ugly scientific stuff (whoo hoo, fun with HDF and netcdf, and GDAL, and). But at the end of all this we'd like to be able to

Re: [Distutils] PYD/SO platform tags (#22980)

On Fri, 12 Dec 2014 23:23:03 + Steve Dower steve.do...@microsoft.com wrote: Hi distutils-sig, There's a bit of discussion going on at http://bugs.python.org/issue22980 about extending SO tags to include bitness values, and I took the opportunity to look into adding platform tags for

Re: [Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

On Sun, 30 Nov 2014 01:47:16 +1000 Nick Coghlan ncogh...@gmail.com wrote: On 29 November 2014 at 01:51, Antoine Pitrou solip...@pitrou.net wrote: On Sat, 29 Nov 2014 01:27:44 +1000 Nick Coghlan ncogh...@gmail.com wrote: Is this not going to be a slippery slope? Only if folks publish

Re: [Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

On Sun, 30 Nov 2014 03:02:57 +1000 Nick Coghlan ncogh...@gmail.com wrote: Many users (quite reasonably, if they're primarily Python developers) have problems working through build failures when attempting to install non-Python extensions from source. Such build failures are usually models of

Re: [Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

On Fri, 28 Nov 2014 16:03:59 +1000 Nick Coghlan ncogh...@gmail.com wrote: Here's my proposed change: = The default platform tag is distutils.util.get_platform() with all hyphens - and periods . replaced with underscore _ . If /etc/os-release [N] exists on the system, then

Re: [Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

On Sat, 29 Nov 2014 01:27:44 +1000 Nick Coghlan ncogh...@gmail.com wrote: Is this not going to be a slippery slope? Only if folks publish Linux binaries themselves, and that's still a bad idea (for the same reason publishing distro binaries is already a rare thing for people to do).

Re: [Distutils] Call for information - What assumptions can I make about Unix users' access to Windows?

On Fri, 7 Nov 2014 15:46:36 + Paul Moore p.f.mo...@gmail.com wrote: I'm in the process of developing an automated solution to allow users to quickly set up a Windows box so that it can be used to compile Python extensions and build wheels. While it can obviously be used by Windows

Re: [Distutils] Making a wheel platform-specific?

On Tue, 28 Oct 2014 13:15:09 + Paul Moore p.f.mo...@gmail.com wrote: On 28 October 2014 12:57, Antoine Pitrou solip...@pitrou.net 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

Re: [Distutils] Making a wheel platform-specific?

On Tue, 28 Oct 2014 13:15:09 + Paul Moore p.f.mo...@gmail.com wrote: On 28 October 2014 12:57, Antoine Pitrou solip...@pitrou.net 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

Re: [Distutils] Making a wheel platform-specific?

On Tue, 28 Oct 2014 13:39:32 + Paul Moore p.f.mo...@gmail.com wrote: On 28 October 2014 13:20, Antoine Pitrou solip...@pitrou.net 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

[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

Re: [Distutils] Making a wheel platform-specific?

On Tue, 28 Oct 2014 10:04:17 -0400 Donald Stufft don...@stufft.io wrote: On Oct 28, 2014, at 9:43 AM, Antoine Pitrou solip...@pitrou.net 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

[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

Re: [Distutils] not a supported wheel on this platform

On Tue, 28 Oct 2014 14:44:22 + Paul Moore p.f.mo...@gmail.com 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',

Re: [Distutils] not a supported wheel on this platform

On Tue, 28 Oct 2014 15:03:23 + Paul Moore p.f.mo...@gmail.com wrote: On 28 October 2014 14:51, Antoine Pitrou solip...@pitrou.net wrote: Does matching really happen that way? Unfortunately yes :-( get_supported() introspects the system you're installing on and builds a list of tag

Re: [Distutils] Create formal process for claiming 'abandoned' packages

Donald Stufft donald at stufft.io writes: The problem with cruft is they make it more difficult to find things for end users who often times don't know what they are looking for. This is especially bad when you have a once popular library/tool for which the maintainer is no longer available.

Re: [Distutils] Create formal process for claiming 'abandoned' packages

Donald Stufft donald at stufft.io writes: PyPI inherinently has complete control over who owns what name on PyPI. Political authority does not derive from technical control, though. As Toshio said that are situations where it makes *obvious* sense to transfer ownership of a project. Using

Re: [Distutils] Create formal process for claiming 'abandoned' packages

Ethan Furman ethan at stoneleaf.us writes: On 09/19/2014 04:13 PM, Alex Gaynor wrote: I **strongly** concur with James here. This has flagrantly violated my trust in PyPI. I would much rather packages not be reclaimed than need to think about whether I trust the PyPI maintainers to do

Re: [Distutils] Accepting PEP 440: Version Identification and Dependency Specification

Hi, Nick Coghlan ncoghlan at gmail.com writes: I just pushed Donald's final round of edits in response to the feedback on the last PEP 440 thread, and as such I'm happy to announce that I am accepting PEP 440 as the recommended approach to identifying versions and specifying dependencies

[Distutils] classifiers not up to date on testpypi

Registering pathlib to https://testpypi.python.org/pypi Server response (400): Invalid classifier Programming Language :: Python :: 3.4 ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Setuptools 2.0 Released

Hi, Jason R. Coombs jaraco at jaraco.com writes: The PyPA is pleased to announce the Setuptools 2.0 release.   This backward-incompatible release drops support for Python 2.4 and Python 2.5, but is otherwise compatible with 1.x releases. Is there a changelog? Regards Antoine.

Re: [Distutils] PEP 453 Round 2 - Explicit bootstrapping of pip in Python installations

Nick Coghlan ncoghlan at gmail.com writes: On 16 Sep 2013 20:06, Antoine Pitrou antoine at python.org wrote: Hi, Donald Stufft donald at stufft.io writes: This is also a matter of starting as we mean to continue: similar to IDLE (see PEP 434), ``getpip`` will be permanently

  1   2   >