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

Change by Alex Waygood : -- nosy: +ned.deily ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by Illia Volochii : -- keywords: +patch pull_requests: +29983 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31885 ___ Python tracker ___

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

Change by Illia Volochii : -- nosy: +pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

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

NumPy Python 3.10.0rc1 wheels.

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, Char

[issue42022] Allow ensurepip to work without bundled wheels

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

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

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

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

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

[issue42022] Allow ensurepip to work without bundled wheels

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

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

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

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

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

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

Change by Kyle Altendorf : -- nosy: +altendky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

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,

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

Change by Kevin Puetz : -- nosy: +vinay.sajip ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

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

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

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

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

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

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

hem 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

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

ste 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}

Building manylinux wheels & auditwheel

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://githu

Re: Packaging multiple wheels in the same package

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

Re: Packaging multiple wheels in the same package

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

Re: Packaging multiple wheels in the same package

, 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

Re: Packaging multiple wheels in the same package

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 > &g

Re: Packaging multiple wheels in the same package

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

Re: Packaging multiple wheels in the same package

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

Packaging multiple wheels in the same package

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

Re: Wheels For ...

ryone 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

Re: Wheels For ...

oper 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 sec

Re: Wheels For ...

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

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

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; exam

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

o 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

Re: Wheels For ...

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

Wheels For ...

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

Re: Wheels For ...

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

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

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