Mailman 3 July 2018 - Distutils-SIG

[Distutils]PEP 518 - pyproject.toml with no build-system.requires
by Pradyun Gedam 21 Jul '18

21 Jul '18

Hey everyone! In PEP 518, it is not clearly specified how a project that has a pyproject.toml file but has no build-system.requires should be treated (i.e. build-system table). In pip 10, such a pyproject.toml file was allowed and built with setuptools and wheel, which has resulted in a lot of projects making releases that assumed that such a pyproject.toml file is valid and they use setuptools and wheel. I understand that at least pytest, towncrier and Twisted might have done so. This happened since these projects have included configuration for some tool in pyproject.toml (some of which use only pyproject.toml for configuration -- black, towncrier). There's a little bit of subtlety here, in pip 10's implementation: adding a pyproject.toml file enables a new code path that does the build in isolation (in preparation for PEP 517; it's a good idea on it's own too) with only the build-system.requires packages available. When the build-system.requires key is missing, pip falls back to assuming it should be ["setuptools", "wheel"]. The in-development version of pip currently prints warnings when the key is not specified -- along the lines of "build-system.requires is missing" + "A future version of pip will reject pyproject.toml files that do not comply with PEP 518." and falls back to legacy behavior. Basically, pip 10 has a distinction between a missing pyproject.toml and build-system.requires = ["setuptools", "wheel"] and the PEP doesn't. However, the PEP's precise wording here would help inform the debate about how pip should behave in this edge case. I can think of at least 2 options for behavior when build-system.requires is missing: 1. Consider a missing build-system.requires equivalent to either a missing pyproject.toml or build-system.requires = ["setuptools", "wheel"]. 2. Making the build-system table mandatory in pyproject.toml. I personally think (2) would be fine -- "Explicit is better than implicit." It'll be easy to detect and error out in this case, in a way that it's possible to provide meaningful information to the user about what to do here. However, this does mean that some existing releases of projects become not-installable, which is concerning; I do think the benefits outweigh the costs though. Thoughts on this? Cheers, Pradyun

10 69

[Distutils]Need help regarding Python and DB2 connectivity
by Shivam Satija 21 Jul '18

21 Jul '18

Hi, I am trying to connect IBM DB2 with python. I am using Python 3.6.0 and want to know if the DB2 connectivity is even possible with this version of python? I have read at various places that only versions 2.x and 3.4 are supported. Is this the case? I am not able to run basic commands like import ibm_db on python 3.6. Thanks, Shivam

3 2

[Distutils]Approaching wheel 1.0
by alex.gronholm＠nextday.fi 20 Jul '18

20 Jul '18

Today I pushed 29 new commits to the pypa/wheel repository, closing around 15 issues. This is a major overhaul/refactoring of the wheel project. Here's the short list of major changes: * The documentation has been rewritten to conform to PyPA guidelines (h ttps://gist.github.com/qwcode/8431828) * Wheel signing and verifying features were stripped out, as they were scarcely used and would have potentially presented a significant maintenance burden * The wheel install feature was also stripped out, largely from the same reason as above * Added a new command, "wheel pack" that will create a new wheel file from a previously unpacked wheel directory, regenerating the RECORD file in the process * Added a new metadata key, "license_files" which can be used to include multiple license files in wheels (this deprecates the "license_file" key) There are still a few issues to work out before I'm comfortable releasing 1.0.0 final. For that, I would like to enlist the help of the Python packaging community, as I may not have the necessary expertise: * Py_UNICODE_SIZE / WITH_PYMALLOC / Py_DEBUG on Windows: https://github .com/pypa/wheel/issues/171 * Supporting tools like milksnake by allowing platform specific wheel tags with ABI set to "none": * https://github.com/pypa/wheel/issues/125 * https://github.com/pypa/wheel/issues/153 * https://github.com/pypa/wheel/issues/175 * https://github.com/pypa/wheel/issues/185 * Automatically detecting C extensions that use the limited ABI and tagging wheels without an explicit --py-limited-abi: https://github.com /pypa/wheel/issues/198 * bdist_wheel not cleaning build directory (really a distutils problem, but can wheel reasonably do something here?) https://github.com/pypa/wh eel/issues/117 I mostly need help defining the concrete steps to take to resolve these issues.

2 1

[Distutils]Introducing XAR - SquashFS based mountable executables - Calling OS/Distro Maintainers
by Cooper Ry Lees 19 Jul '18

19 Jul '18

Hi distutils, Today Facebook Open Sourced a competitor to PEX and other zip based distribution methods for Python (and potentially other languages). Basically it's claim to fame is start up time for large modules being similar to regular on file system modules due to extracting on read via SquashFS mounted executables. For more information read our blog post: - https://code.fb.com/data-infrastructure/xars-a-more-efficient-open-source-s… <https://code.fb.com/data-infrastructure/xars-a-more-efficient-open-source-s…> The bdist_xar 'wheel' like plugin is also now in PyPI: https://pypi.org/project/xar/ <https://pypi.org/project/xar/> (https://github.com/facebookincubator/xar/ <https://github.com/facebookincubator/xar/>). Main reason I wanted to post here was I'd love to reach out to our OS maintainers on list (e.g. Mr Stinner) and talk about getting the components of XAR into the OS's package repos. The main components that make sense are: - xarexec_fuse: https://github.com/facebookincubator/xar/ <https://github.com/facebookincubator/xar/> - squashfuse: a newer version with squashfuse_ll (and optionally zstd support) https://github.com/vasi/squashfuse <https://github.com/vasi/squashfuse> - squashfs-tools: a newer version with zstd support (made optional I guess) Once we had this, it would make building XARs as easy as building wheels, even more so when we can define OS level dependencies for it! Please feel free to reach out to me directly with any questions etc. - Also want to note, Sumanah suggested I floated this here, I apologize if this is a misuse of the list. If so, please ignore. I was torn wether or not this is appropriate. Thanks, Cooper

6 9

[Distutils]how can I install packages of python 3.7 on window 10
by HIMANSHU SATYWALI 19 Jul '18

19 Jul '18

Sent from Mail for Windows 10ws 10

1 0

[Distutils]Re: The Wheel specification and compatibility tags on Windows
by Cosimo Lupo 17 Jul '18

17 Jul '18

I would like to revive this 5 year old thread and see if we can stir things up a bit. Basically the problem is that, in the current state of the PEPs and build tools, it is still not possible to build and distribute a Windows wheel that includes an extension module compiled with Py_LIMITED_API. Setuptools can successfully build such extension module on Windows (with `.pyd` file extension and no extra specifiers in the module filename), and these seems to work at least on CPython 3.5 and above. However the `--py-limited-api cpXX` option of bdist_wheel command fails on Windows because it attempts to use the `abi3` tag but the latter is not in the list of compatible tags for that platform. One can work around this by creating a wheel with `none` as the abi tag, and `cp35.cp36.cp37` as the python implementation tag but this feels a bit hackish. Here are some unresolved questions from the old distutils-sig thread, quoting Paul Moore: > 2. How should tools determine which ABIs a given Python supports? > (This is the get_supported function in wheel and distlib). The "Use" > section of the PEP (http://www.python.org/dev/peps/pep-0425/#id1) > gives a Linux-based example, but nothing normative and nothing that is > understandable to a Windows user. And from Vinay Sajip > For Windows, we (eventually) need some low-level sysconfig-supported way > to get the ABI information in an analogous way to how it happens on POSIX: and > because that's not currently there, distlib doesn't provide any ABI information > on Windows other than "none". Other related links: https://github.com/pypa/pip/issues/4445 https://mail.python.org/pipermail/distutils-sig/2018-January/031856.html So.. what needs to be done here to allow distributing/installing Windows wheels with Py_LIMITED_API support? Thank you, Cosimo Lupo -- Cosimo Lupo

6 8

[Distutils]Package maintainers: verify your PyPI account email address
by Sumana Harihareswara 17 Jul '18

17 Jul '18

Heads-up: if you have a pypi.org or test.pypi.org account, please verify your email address: https://pypi.org/manage/account/ https://test.pypi.org/manage/account/ Reason: > We have a problem with a bit of our data, namely that due to historical reasons we have a fair amount of users in the database that do not have a verified primary email address. The side effect of this is that we're currently sending emails to email addresses that we have not had verified. This is a bad situation to be in, because in order to keep our bounce/spam rate low, we should be confirming all email addresses before sending email to them. In addition the way our bounce handling code works is it un-verifies the email address, which the intent was to stop sending email to it until the user has reverified their email address. > > In total there are about 193k user accounts with a unverified email address for their primary address, and 44k that do have a verified email address for their primary account. > > So we need to come up with a strategy to resolve this, because it's pretty important that we don't send email to unverified addresses. (quoting from Donald Stufft's explanation https://github.com/pypa/warehouse/issues/3632 which goes on to detail the step-by-step plan) Package maintainers should especially do this soon. As of a few days ago, any user whose primary email address is unverified can't upload a file: https://github.com/pypa/warehouse/pull/4292 Please forward to other package maintainers. After we iron out any issues I figure we'll email the announce list https://mail.python.org/mm3/mailman3/lists/pypi-announce.python.org/ . -- Sumana Harihareswara Changeset Consulting https://changeset.nyc

1 0

[Distutils](no subject)
by phung237337＠gmail.com 16 Jul '18

16 Jul '18

Được gửi từ Yahoo Mail trên Android

1 0

[Distutils]ssl error in installing packages
by Nitin Thakur 16 Jul '18

16 Jul '18

SSL-CERTIFICATE-VERIFICATION FAILED while installing packages using pip command. Sent from Mail for Windows 10

3 2

[Distutils]pypi/twine complains about license
by Robin Becker 13 Jul '18

13 Jul '18

After release of Python-3.7 I wanted to upload to pypi a newly built version of a C-extension which already has been migrated to the new site. $ twine --version twine version 1.11.0 (pkginfo: 1.4.2, requests: 2.18.1, setuptools: 36.2.0, requests-toolbelt: 0.8.0, tqdm: 4.14.0) $ twine upload *.whl Uploading distributions to https://upload.pypi.org/legacy/ Uploading pyRXP-2.1.1-cp37-cp37m-manylinux1_i686.whl 100%|████████████████████████████████████████████████████████████████████████████████████████████████████| 104K/104K [00:00<00:00, 141KB/s] HTTPError: 400 Client Error: Invalid value for classifiers. Error: 'License :: OSI Approved :: ReportLab BSD derived' is not a valid choice for this field for url: https://upload.pypi.org/legacy/ 1) I think it is completely wrong for twine/pypi to fail to upload because of the license field. The license is derived from BSD and the same string is present in the previously uploaded versions of this package. What are valid licenses? Presumably pypi is now a gatekeeper for the license police. 2) I looked in vain on the new pypi.org site for a manual upload mechanism. Is this now frowned on? 3) I was able to upload the same package several times without error; does this mean I am overwriting the file? -- Robin Becker

12 25