Mailman 3 October 2018 - Distutils-SIG

Announcing Wheelodex
by John Thorvald Wodder II 19 Oct '18

19 Oct '18

I've created a website that is likely to be of interest to people here: Wheelodex <https://www.wheelodex.org>, a site for browsing the metadata of wheels on PyPI. It allows you to find out what projects a wheel depends on, what other projects depend on a given project, what commands & other entry points a wheel defines, what files are in a wheel, etc. You can even search for wheels containing a given module or file, or browse a list of all commands & other entry points defined by wheels. There's also a basic API for getting wheel data as JSON: <https://www.wheelodex.org/json-api/>. I'm open to suggestions on what else to do with the data. I'm also open to suggestions on how to make the interface look less sucky. -- John Wodder

6 5

Re: [Distutils] [Python-ideas] Pypi private repo's
by Alex Walters 17 Oct '18

17 Oct '18

I am fairly sure if you give the PyPA that suggestion, they will just deflate at the thought of the workload. Besides, we already offer private repos for free, several ways ranging from devpi to python -m SimpleHTTPServer in a specially created directory. From: Python-ideas <python-ideas-bounces+tritium-list=sdamon.com(a)python.org> On Behalf Of Nick Humrich Sent: Wednesday, April 4, 2018 12:26 PM To: python-ideas(a)python.org Subject: [Python-ideas] Pypi private repo's I am sure this has been discussed before, and this might not even be the best place for this discussion, but I just wanted to make sure this has been thought about. What if pypi.org <http://pypi.org> supported private repos at a cost, similar to npm? This would be able to help support the cost of pypi, and hopefully make it better/more reliable, thus in turn improving the python community. If this discussion should happen somewhere else, let me know. Nick

5 5

manylinux1 guidelines for zlib?
by Antoine Pitrou 15 Oct '18

15 Oct '18

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 the zlib as part of a manylinux1 wheel? Would you recommend static linking with a private version, or dynamic linking? Regards Antoine.

4 6

History of python packaging
by Константин 15 Oct '18

15 Oct '18

Hello! My name is Konstantin and I am going to participate in the PyPA event [1] next week. To understand the packaging landscape better, I've decided to create an article for myself generally, but I think it could be interesting for others as well because I've found that https://www.pypa.io/en/latest/history/ is not enough for me to understand how packaging works in general. If anyone has an interest, I would really appreciate any comments on it, either technical or just stylistic. https://medium.com/@knikitin/the-brief-history-of-package-distribution-in-p… , before I will publish it for a wider audience. Thank you! [1] https://generalassemb.ly/education/bloomberg-open-source-weekend-pypa/londo…

3 3

setuptools API compatibility
by brian＠sweetapp.com 11 Oct '18

11 Oct '18

Hi, Does setuptools make any API stability guarantees i.e. should all setup.py files that work with setuptools version X also work with setuptools version Y where Y > X? I'm asking because the App Engine Python 3.7 runtime keeps it's version of setuptools up-to-date and I'm wondering if that is problematic due to API compatibility i.e. that package installation might fail due to an incompatibility introduced in setuptools. Cheers, Brian

5 5

[poposal for preparing a pep] sharing package installations between virtualenvs
by RonnyPfannschmidt 08 Oct '18

08 Oct '18

hi everyone, i just did a little spring cleaning, and while i cleaned up my ~/Projects folder - the vast amount of that was virtualenvs with roughly the same packages installed - each about 500 mb for like 2-5 mb of code this seems excessively wasteful - my impression is that ~98% of the files seem to be duplicate. since the impending eol of python2 and the multi python version capabilities of python3 compiled code caches, i'd like to create a proposal for a shared folder structure $LIB/python/shared-packages/ should be a root folder in which unpacked wheels would reside at a initial iteration this solution would suffer from the expanding python path issue since each package would have a toplevel sys.path entry. on order to later on speed this up a simple api can be provided that makes python aware of the metatadata locations and the map toplevel/namespace names directly to import locations for example like shared-packages.pth import sys;sys.path.insert(0, "$LIB/python/shared-packages/shared_packages_support-1.0-py3.whl/"); import shared_packages_support;sys.path.pop(0);shared_packages_support.enable() shared_packages.json { "pytest": "pytest-3.8.8-py2.py3.whl"; } in the aftermath, when shared packages support and fast import/metadata for shared packages where implemented, the sizes of most virtualenvs would shrink significantly -- Ronny

5 6

Send
by youtube.com/ [whatItSaysHere] 06 Oct '18

06 Oct '18

1 0

world-wirde
by youtube studio 05 Oct '18

05 Oct '18

Good

1 0

pip 18.1 has been released!
by Pradyun Gedam 05 Oct '18

05 Oct '18

On behalf of the PyPA, I am pleased to announce that pip 18.1 has just been released. To install pip 18.1, you can run:: python -m pip install --upgrade pip or use get-pip as described in https://pip.pypa.io/en/latest/installing. Note that if you are using a version of pip supplied by your distribution vendor, vendor-supplied upgrades will be available in due course. The highlights of this release are: - Python 3.7 is now supported - Dependency Links support is now scheduled for removal in pip 19.0 (the next pip release, scheduled in January 2019). - Plaform specific options can now be used with the --target option, to enable certain workflows. - Much more helpful error messages on invalid configuration files - Many bug fixes and minor improvements Thanks to everyone who put so much effort into the new release. Many of the contributions came from community members, whether in the form of code, participation in design discussions and/or bug reports. The pip development team is extremely grateful to everyone in the community for their contributions. Thanks, Pradyun

1 0

Re: disable building wheel for a package
by Jeroen Demeyer 04 Oct '18

04 Oct '18

On 2018-09-14 12:55, Alex Grönholm wrote: > I'm curious: what data does it attempt to install and where? Have you > created a ticket for this somewhere? The OP mentioned absolute paths. However, it really sounds like a bad idea to hard-code an absolute installation path. Let's consider it a feature that wheel doesn't support that. See https://github.com/pypa/wheel/issues/92

16 76