Mailman 3 June 2017 - Distutils-SIG

Python 3.6
by Ken R. Lewis 25 Jun '17

25 Jun '17

Hello! I am new to Python as I just downloaded it today. I have a script I need to run that has "requests" in it. How do I go about getting this set up? Also, I am on a Windows 7 machine. Here is the code: #Need to install requests package for python #easy_install requests import requests thanks, Ken Ken Lewis Trinity Health I.T. Programmer Lead (701) 858-6423 Cell (701)833-8234 Fax (701) 858-6407 Ken.Lewis(a)trinityhealth.org<mailto:Ken.Lewis@trinityhealth.org> ________________________________ Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is privileged, confidential, or otherwise exempt from disclosure under applicable law. Any unauthorized review, copy, use, disclosure or distribution is prohibited. If you have received this communication in error, please delete it from your system without copying or forwarding it and notify the sender of the error by reply e-mail.

2 1

Can u provide metadata about the PyPI
by Priya Lakshmi 24 Jun '17

24 Jun '17

Respected Python expert I just want a help. Can u provide us the metadata available about the modules in PyPI giant database. For example, we want the number of packages available, the number of downloads for each package, etc.... So we can think of doing some good maintenance work. thank you. G Priyalakshmi Assistant Professor (Selection Grade) Department of Applied Mathematics and Computational Sciences PSG College of Technology Coimbatore

2 1

Re: [Distutils] PEP 517: editable installs
by Nathaniel Smith 17 Jun '17

17 Jun '17

On Jun 16, 2017 11:59 AM, "Daniel Holth" <dholth(a)gmail.com> wrote: I noticed PEP 517 uses a prefix for editable installs. Which part of the pep are you looking at? All I see about editable installs is the note saying that they're deferred to a future pep. -n

3 4

PEP 517: Python 3 finder?
by Daniel Holth 17 Jun '17

17 Jun '17

Build systems should be able to run under a different version of Python than the one that is running 'pip install'. Does PEP 517 have anything to say about that? Then a flit back end could have a small amount of Python 2.7 compatible interface code and create the wheel with Python 3 anyway.

6 6

PEP 517: editable installs
by Daniel Holth 16 Jun '17

16 Jun '17

I noticed PEP 517 uses a prefix for editable installs. What enscons needs for development install, which is cribbed from setuptools, is to perform a build-in-place and write to a directory that accepts Python .pth files, essentially adding the build-in-place directory to PYTHONPATH. Enscons uses the 'purelib' directory for editable installs. It adds the source directory of the development package to the path and writes an .egg-link to the 'purelib' directory. pip knows how to uninstall these. The code is in enscons.setup.

1 0

PEP 517: Open questions around artifact export directories
by Nick Coghlan 16 Jun '17

16 Jun '17

Hi folks, Thanks for the recent discussions around the PEP 517 build hooks PEP - I think they've clarified and improved the PEP in several areas and are setting us up well for an interoperability API that is both flexible and straightforward for frontends and backends to support. However, I think they've also raised some new still open questions, which I'd like to discuss specifically in this thread. 1. Should backends create artifacts directly, or simply export their contents, and let frontends assemble them into redistributable archives? 2. Are backends responsible in any way for naming artifacts, or should that responsibility lie entirely with frontends? For the first question, in the latest PEP draft, we have: - the sdist hook is `export_sdist`, with the expected output being a filesystem directory - the metadata hook is `get_wheel_metadata`, with the expected output being the contents of the metadata directory - the wheel hook is `build_wheel`, with the expected output being an already assembled binary wheel archive - the build preparation hook is `prepare_build_files`, with the expected output being the subset of files specfically needed to assemble a full wheel file with `build_wheel` For the second question: - the sdist hook is currently unclear on whether the backend should write the sdist contents directly into the frontend supplied directory, or into a suitably named subdirectory - the metadata hook is explicit that the backend should write the metadata directly into the given directory - the wheel hook is explicit that the backend should create already assembled wheel archives in the given directory - the build preparation hook is explicit that the backend should write the metadata directly into the given directory When considered as a unified specification this seems confusingly inconsistent to me, although understandable given that we started out covering only the well specified wheel format, and eventually expanded it to cover the substantially less well specified notions of sdist archives and temporary build directories. While I'm open to being persuaded otherwise, my current thinking is that these concerns could be suitably addressed by making the following amendments: 1. Move all artifact naming responsibilities to the frontend. All backend hooks would just write files in the defined format into the directory supplied by the frontend (and those directories would have no defined naming scheme - they're just a staging area for the backend to pass content to the frontend) 2. Change the names of the artifact hooks to be "export_sdist_content" and "export_wheel_content" to emphasise that backends are responsible for generating the artifact *contents*, not the artifacts themselves 3. Change the optional metadata preparation hook to be "prepare_wheel_metadata" for consistency with "prepare_build_files". This gives us a consistent naming scheme where the "export_*" hooks are required, but each has an optional "prepare_*" counterpart that backends may implement as a more efficient alternative when the full artifact contents aren't (or may not be) needed. Assuming we add support for building multiple wheels from a single source archive in the future, we'd do this through some kind of declarative API based mechanism like adding a new optional "wheel_name" parameter to `prepare_wheel_metadata` and `export_wheel_content` (to tell the backend which wheel the frontend is interested in), along with an additional field in [build-system] to tell frontends which secondary wheels are defined by that project. Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

8 55

Upcoming change to the packaging.python.org theme (and other PyPA docs)
by Nick Coghlan 15 Jun '17

15 Jun '17

Hi folks, Thanks to Jon Parrott's excellent work, the CPython documentation theme is now pip-installable (directly from git), and there's a PyPA specific derivative of that at https://github.com/pypa/pypa-docs-theme (also intended to be installed directly from git rather than pyPI). The first project to be migrating will be the Python Packaging User Guide, which Jon has posted a preview instance of at http://temp.theadora.io/pypug-pydoctheme/index.html If you'd like to review the related PR, that's at https://github.com/pypa/python-packaging-user-guide/issues/305, while the original discussion leading to the theme change is at https://github.com/pypa/python-packaging-user-guide/issues/304 While the user guide is the first project to switch themes, we expect that other PyPA projects will also switch over at some point (see the issue link above for more details on that). Regards, Nick. P.S. We're aware the new theme has limitations on mobile devices, so if folks would like to address that, the best place to tackle it would be upstream in the CPython docs theme: https://github.com/python/python-docs-theme -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

PyQT python module .
by Catalin George Festila 08 Jun '17

08 Jun '17

Dear python team . I used python 2.7 and 3.4 version and I saw your simple way Installing Python Modules — Python 3.6.1 documentation Installing Python Modules — Python 3.6.1 documentation Hope this mail will help you and your changes will help python users. I think is need to fix some python modules, like: PyQt 4 and 5 with SIP. The main reason is the hard way to install this python modules. Also some python package PyAudio can be install into python 2.7 version but not into 3.4. This python module ( PyAudio ) is need by SpeechRecognition python module. I try also the wheel way , but nothing . For windows I used this : pip-review.exe --auto --verbose and working well with some packages but I got some errors: Rolling back uninstall of mysql-connector Command "C:\Python34\python.exe -u -c "import setuptools, tokenize;__file__='C:\\Users\\mythcat\\AppData\\Local\\Temp\\pip-build-21khqzin\\mysql-connector\\setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record C:\Users\mythcat\AppData\Local\Temp\pip-80abjmph-record\install-record.txt --single-version-externally-managed --compile" failed with error code 1 in C:\Users\mythcat\AppData\Local\Temp\pip-build-21khqzin\mysql-connector\ Thank you. Best regards. Cătălin George Feștilă https://python-catalin.blogspot.ro/

2 1

manylinux1 testing
by Robin Becker 05 Jun '17

05 Jun '17

Are there docker images suitable for testing manylinux packages. I am guessing the manylinux1 images might be suitable, provided I drop all building of libraries inside them and then just use the pythons I want to test against. Reason I'm asking is that I noticed that I was building images where the final grafting didn't seem to be happening I assume something must have been wrong with the repair_wheehouse command. My manylinux1 images were 4 weeks old. The situation improved after I updated today. However, I have been testing these 'bad' wheels and they all appeared to work. Problem is that I'm only bundling freetype, libpng and libz and I guess my test systems all have those. So is it reasonable for me to use the manylinux1 images as a null linux so I can pip load my stuff from the local file system and test it all runs on a system with almost no libraries built in? -- Robin Becker

2 3

Provisionally accepting PEP 517's declarative build system interface
by Nick Coghlan 04 Jun '17

04 Jun '17

Hi folks, I am hereby provisionally accepting PEP 517 as our CLI independent interface for build backends, allowing interested parties to move forward with implementing it as part of pip and other tools. As with other provisionally accepted PyPA interoperability specifications, it won't be considered completely settled until it has been implemented and released in pip and we have at least one iteration of end user feedback. Thanks to Nathaniel & Thomas for their work on the PEP, and to everyone that participated in the related discussions! Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

15 120