[Distutils] Re: Depending on external library

It's necessary to bundle the external library with the wheel. On linux, this is what the manylinux tag is all about (see PEP 513 & 571) and the auditwheel tool (https://github.com/pypa/auditwheel) will bundle the library into the wheel. On OS X and Windows, I'm less familiar with the toolchain

[Distutils] Re: Idea: perennial manylinux tag

Hi, As the original author of auditwheel and co-author of PEP 513, I figure I should probably chime in. I suspect that *I* am one of the major reasons that the manylinux1 -> manylinux2010 transition has been unreasonably drawn out, rather than any particular design flaw in the versioning scheme

Re: [Distutils] Installation problem

This isn't actually the right place to ask for installation help, Aneesh. Your best bet would be the python-list or python-help mailing list. -Robert On Tue, May 30, 2017 at 7:24 PM, Aneesh Kona wrote: > Hi, > I'm getting an error while installing software, > I did

Re: [Distutils] Maintaining a curated set of Python packages

Isn't this issue already solved by (and the raison d'être of) the multiple third-party Python redistributors, like the various OS package maintainers, Continuum's Anaconda, Enthought Canopy, ActiveState Python, WinPython, etc? [image: Inline image 1] -Robert On Thu, Dec 1, 2016 at 4:45 AM,

Re: [Distutils] If you want wheel to be successful, provide a build server.

> I want to get something setup that would allow people to only need to upload > a source release to PyPI and then have wheels automatically built for them > (but not mandate that- Projects that wish it should always be able to control > their wheel generation). I don’t know what that would

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

On Tue, Feb 16, 2016 at 4:10 PM, Glyph Lefkowitz wrote: > > This whole section is about a tool to automatically identify possible > issues with these wheels - > https://www.python.org/dev/peps/pep-0513/#auditwheel - so I don't even > really know what you mean by this

Re: [Distutils] Alternative build system abstraction PEP

> ... The ideal would be that there would be a single static pypackage.cfg that could be dropped into any "version 0" VCS checkout to convert I think you mean "pypackage.json" here, not .cfg? -Robert On Tue, Feb 16, 2016 at 8:43 PM, Robert Collins wrote: > Cool.

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

> 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 `--enable-shared`. I don't know that their reasons are, but I presume that the Debian maintainers have

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

python Conflicts: python-pyside.qtcore:i386 ``` -Robert On Sun, Feb 7, 2016 at 2:06 PM, Matthew Brett <matthew.br...@gmail.com> wrote: > On Sun, Feb 7, 2016 at 4:38 AM, Antoine Pitrou <solip...@pitrou.net> > wrote: > > On Sun, 7 Feb 2016 00:25:57 -0800 > > "Rober

Re: [Distutils] setup('postinstall'='my.py')

One very simple technique used by some projects like numpy is just to have ``setup.py`` write a file into the source tree before calling setup(). example: https://github.com/numpy/numpy/blob/master/setup.py#L338-L339 -Robert On Tue, Feb 2, 2016 at 1:48 PM, AltSheets Dev <

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

On Mon, Feb 1, 2016 at 3:47 PM, Alexander Walters wrote: > > > On 2/1/2016 18:37, Matthias Klose wrote: > >> On 30.01.2016 00:29, Nathaniel Smith wrote: >> >>> Hi all, >>> >>> I think this is ready for pronouncement now -- thanks to everyone for >>> all their feedback

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

Oh yes, this is very important! I will have to put a check in auditwheel as well to verify this in the extensions too. -Robert ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] How to get pip to really, really, I mean it -- rebuild this damn package!

The pip wheel cache is in ~/Library/Caches/pip/wheels (OS X) or ~/.cache/pip/wheels (Linux). I'm not sure about Windows. You might have some luck deleting files from there. -Robert On Thu, Jan 28, 2016 at 4:28 PM, Chris Barker wrote: > Context: > > I'm maintaining a

Re: [Distutils] PEP 513: A Platform Tag for Portable Linux Built Distributions Version

The file pip uses to record its latest check for being out of date (on linux ~/.cache/pip/selfcheck.json) is a json file that maps the path to the interpreter's sys.prefix to some metadata about the installation e.g. {"/home/rmcgibbo/opt/python-3.5/":

Re: [Distutils] PEP 513: A Platform Tag for Portable Linux Built Distributions Version

Virtualenvs have `sys.base_prefix`, so perhaps they could just check whether the key exists for their parent environment? -Robert On Tue, Jan 26, 2016 at 1:37 PM, Nathaniel Smith <n...@pobox.com> wrote: > On Jan 26, 2016 1:04 PM, "Robert T. McGibbon" <rmcgi...@gmail.com>

Re: [Distutils] draft PEP: manylinux1

On Mon, Jan 25, 2016 at 10:29 PM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > Given that we're starting now ( not a year or two ago) and it'll take > a while for it to really catch on, we should go CentOS 6 ( or > equivalent ) now? > > CentOS5 was released in 2007! That is a

Re: [Distutils] PEP 513: A Platform Tag for Portable Linux Built Distributions Version

I agree that this is an important detail. I generally use machines that have many different Python interpreters installed (some distro-provided and others in my home directory), and can easily imagine wanting them to have different behavior w.r.t. manylinux1 wheels. Perhaps the option could be

Re: [Distutils] PEP 513: A Platform Tag for Portable Linux Built Distributions Version

Alternatively, perhaps this question could be delegated to the pip maintainers, for pip to store and maintain this configuration option itself, perhaps by using its cache (for example, Linux pip already stores some caches in ~/.cache/pip)? -Robert On Mon, Jan 25, 2016 at 8:37 PM, Robert T

[Distutils] PEP 513: A Platform Tag for Portable Linux Built Distributions Version

: https://github.com/manylinux/manylinux/blob/master/pep-513.rst -Robert PEP: 513 Title: A Platform Tag for Portable Linux Built Distributions Version: $Revision$ Last-Modified: $Date$ Author: Robert T. McGibbon <rmcgi...@gmail.com>, Nathaniel J. Smith <n...@pobox.com> BDFL-Delegate:

Re: [Distutils] draft PEP: manylinux1

On Sat, Jan 23, 2016 at 6:19 PM, Chris Barker wrote: > > 1) each package that needs a third partly lib statically links it in. > 2) each package that needs a third partly lib provides it, linked with a > relative path (IIUC, that's how most Windows packages are done. >

Re: [Distutils] draft PEP: manylinux1

On Jan 22, 2016 9:04 AM, "Lowekamp, Bradley (NIH/NLM/LHC) [C]" < blowek...@mail.nih.gov> wrote: > > Hello, > > I noticed that libpython is missing from the lists of dependent libraries. Also the “manylinux” Docker image has it’s Python versions compiled with libpython static. > > Does this mean

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 8:53 AM, M.-A. Lemburg wrote: > [...] > What we need is a system that provides a few dimensions > for various system specific differences (e.g. bitness, > architecture) and a recommendation for library > versions of a few very basic libraries to use when

Re: [Distutils] draft PEP: manylinux1

On Jan 21, 2016 11:55 AM, "Chris Barker" wrote: > > On Thu, Jan 21, 2016 at 11:37 AM, Nathaniel Smith wrote: >> >> Glyph told us last week that this proposal is exactly how the cryptography package wants to handle their openssl dependency:

Re: [Distutils] draft PEP: manylinux1

On Jan 21, 2016 12:04 PM, "Matthias Klose" wrote: > so this is x86_64-linux-gnu. Any other architectures? Any reason to choose gcc 4.8.2 which is known for it's defects? I'm not aware of those defects. Can you share more information? -Robert

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 7:29 PM, Donald Stufft <don...@stufft.io> wrote: > > On Jan 21, 2016, at 10:27 PM, Robert T. McGibbon <rmcgi...@gmail.com> > wrote: > > I'm hopeful that in the future, if this PEP is accepted > and we can make the tooling and documentat

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 9:23 AM, Donald Stufft wrote: > > >> On Jan 21, 2016, at 4:31 AM, Nick Coghlan wrote: > >> If Donald can provide the list of "most downloaded wheel files" for > >> other platforms, that could also be a useful guide as to how many > >>

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 7:19 PM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: Cool! Are the non-manylinux dependencies all statically linked? > No, they're not statically linked. They're vendored inside the wheel using ``auditwheel repair``. -Robert

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 7:32 PM, Nick Coghlan wrote: > > However, it does suggest a possible alternative approach to naming > these compatibility subsets: what if the name of this particular > platform compatibility tag was something like "linux-sciabi1", rather > than

Re: [Distutils] draft PEP: manylinux1

On Thu, Jan 21, 2016 at 6:47 PM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > Maybe the infrastructure has improved, and the community grown enough, > that this will all work. We'll see. > Yeah, that's my hope too. Currently, the community lacks the permissions to upload Linux