Mailman 3 August 2016 - Distutils-SIG

cffi & Py_LIMITED_API
by Daniel Holth 20 Aug '16

20 Aug '16

The next version of cffi will contain small changes to generate code compliant with Python's Py_LIMITED_API: https://bitbucket.org/cffi/cffi/commits/8f867f5a869f (although cffi itself is not, the extensions it generates will be). If we also add an appropriate supported tag to pip ~= cp3.abi3.manylinux1 and provide a way to name the generated DLL's appropriately, it may become possible to reduce the burden of distributing cffi extensions, especially for Windows. One compiled artifact should work on Python 3.2 and above.

3 8

Future of setuptools and buildout
by Leonardo Rochael Almeida 20 Aug '16

20 Aug '16

Spinning this off into its own thread... On 16 August 2016 at 13:10, Donald Stufft <donald(a)stufft.io> wrote: > > On Aug 16, 2016, at 11:15 AM, Leonardo Rochael Almeida < > leorochael(a)gmail.com> wrote: > > Specifically, buildout right now has setuptools as its only dependence, > and buildout uses it to locate, download and build sdist dependencies, or > directly download and use .egg dependencies, which are important for > Windows platforms in the communities that use buildout and depend on > compiled extensions. > > > > Ah, I knew I was forgetting something. I think we should hold off on > preventing egg uploads until setuptools can download and install wheels. > Which brings us to a question that I'm meaning to ask for a while. It looks like we're close to removing all mentions of setuptools in pip. When this happens, it looks like pressure is going to start to mount on setuptools to drop the ability to install packages and limit itself on being just a build tool. It makes sense that it should be so, considering that there would be no incentive to keep around two distinct implementations of how to locate, download and install stuff, one in pip (or whatever library pip uses for locating and installing packages) and another in setuptools. In this future, I can imagine setuptools will simply complain loudly when the packages it requires to do its work are not installed yet, perhaps with a plugin mechanism for allowing another package to automatically resolve and installing packages, (like today setuptools-git extends setuptools to recognize files from git to be included in a package). And people will promptly write a pip implementation of this plugin (or whatever it is that pip will use as a library to do it)... thereby inverting the dependency between setuptools and pip. When this future arrives, buildout will be out of a mechanism for locating, downloading and installing packages (not counting old versions of setuptools, of course). Questions: 1. Is the future outlined above considered likely? 2. If this future arrives, what package should buildout be ported to use? It should provide: * The ability to locate packages and their versions, resolve their dependencies, and download them, whether they're sdists or wheels (or eggs, while we still have them) * Install each package separately into it's own directory that, if added to `sys.path`, allows this same package (or perhaps another one) to read information from entry points so that buildout can locate its own extensions and install console scripts. Regards, Leo

8 13

Deprecating little used file types/extensions on PyPI?
by Wes Turner 17 Aug '16

17 Aug '16

PEX - Python Executable - It's a ZIP with an executable header and entry points. - PEX probably solves for the AWS Lambda case - PEX is unsupported by PyPI (e.g. sadly doesnt work with DevPi application-level package repository caching) http://pex.readthedocs.io/en/stable/ https://github.com/pantsbuild/pex - PantsBuild builds PEX packages (Twitter) - Buck Build builds PEX packages (Facebook) Wheel adds a manifest of checksums (which should be signed, correct?) - https://bitbucket.org/pypa/wheel/issues/168/code-to-add-a-wheel-manifest-to… Wheel does not solve for everything eggs still solve for. Neither are perfect: - https://bitbucket.org/pypa/wheel/issues?status=new&status=open - Wheel doesn't support environment markers in requirements.txt - - https://bitbucket.org/pypa/wheel/issues/168/code-to-add-a-wheel-manifest-to… What is the need to reduce/simplify the supported package types? Each have their strengths. "Suddenly they wouldn't accept archives which execute arbitrary code anymore " I say support them all and don't waste time with complex deprecation and migration strategies when the code already works. What's it hurting to continue legacy support? (E.g., specifically, instead of throwing a distribution stat up and claiming need to eliminate everything legacy or exotic, what are the costs for each option here? Approaches: - deprecate legacy and goad migration - continue supporting a diverse array of python packaging needs Costs: - end user developer time - pypa developer time - pypa server time On Wednesday, August 17, 2016, Nick Coghlan <ncoghlan(a)gmail.com <javascript:_e(%7B%7D,'cvml','ncoghlan(a)gmail.com');>> wrote: > On 17 August 2016 at 23:23, Steve Dower <steve.dower(a)python.org> wrote: > > Do you mean like zipapp and *.pyz files? > > Pretty much, yeah, but with a more fleshed out workflow that accounts > for dependency bundling as well - you'd have a relatively normal > Python app with a setup.py and/or requirements.txt, but be able to > readily package the whole thing up for distribution. > > This kind of thing is *possible* today if you already know what you're > doing, and at least the AWS Lambda docs are pretty decent when it > comes to describing how to make it work in their (non-zipapp) usage > model: http://docs.aws.amazon.com/lambda/latest/dg/lambda-python- > how-to-create-deployment-package.html > (I haven't checked the Azure Compute Function docs, and Google Compute > Function is currently JavaScript only) > > However, these kinds of approaches are nowhere near as well fleshed > out from an automation perspective as traditional Linux web service > deployment - note that there's no mention in the AWS Lambda docs of > using a requirements file rather than individual dependency > installations. > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG(a)python.org > https://mail.python.org/mailman/listinfo/distutils-sig >

2 1

Re: [Distutils] Deprecating little used file types/extensions onPyPI?
by Nick Coghlan 17 Aug '16

17 Aug '16

On 17 August 2016 at 23:23, Steve Dower <steve.dower(a)python.org> wrote: > Do you mean like zipapp and *.pyz files? Pretty much, yeah, but with a more fleshed out workflow that accounts for dependency bundling as well - you'd have a relatively normal Python app with a setup.py and/or requirements.txt, but be able to readily package the whole thing up for distribution. This kind of thing is *possible* today if you already know what you're doing, and at least the AWS Lambda docs are pretty decent when it comes to describing how to make it work in their (non-zipapp) usage model: http://docs.aws.amazon.com/lambda/latest/dg/lambda-python-how-to-create-dep… (I haven't checked the Azure Compute Function docs, and Google Compute Function is currently JavaScript only) However, these kinds of approaches are nowhere near as well fleshed out from an automation perspective as traditional Linux web service deployment - note that there's no mention in the AWS Lambda docs of using a requirements file rather than individual dependency installations. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

Re: [Distutils] license for setuptools
by Marinier, Claude 17 Aug '16

17 Aug '16

> Date: Fri, 12 Aug 2016 02:45:20 +0000 > From: Eric Dill <thedizzle(a)gmail.com> > Subject: Re: [Distutils] license for setuptools > > Hi Claude, > > There was a recent discussion of the lack of a license file in setuptools > here: https://github.com/pypa/setuptools/issues/612 and another important > discussion here: https://github.com/pypa/setuptools/issues/132. This is > probably the most relevant quotable bit from those two issues, from Jason > Coombs (the primary developer of setuptools: > > "The [License :: OSI Approved :: MIT License] classifier isn't a suggestion but a > declaration and follows the distutils guide for declaring a license. > I consider inclusion of a license file redundant and error prone." > > Hopefully this resolves your issue about not having an explicit license file. Thank you Eric and the others. I will use this information for the request. -- Claude Marinier

2 1

Pip maintainers contact
by hyp3rlinx 15 Aug '16

15 Aug '16

Can somebody here please tell me the contact email for maintainers of pip. Thank you, John

2 1

Re: [Distutils] license for setuptools
by Nick Coghlan 14 Aug '16

14 Aug '16

On 13 Aug 2016 04:53, "Nick Timkovich" <prometheus235(a)gmail.com> wrote: > > Might be wandering away from simply tacking on a license, but some related legalese: Is there some canned contributor license agreement (CLA) that could also be applied to make clear that contributors must license their contributions to the project(s) in kind? Python has it's own ( https://www.python.org/psf/contrib/) but that seems very formal. Is there a simpler one that just makes it implicit that 'submitting a patch/PR = you agree to license that code to the project for redistribution" or whatever. "Licence in = licence out" is the implied default for contributions when there's no formal contributor agreement to specify otherwise. (I'm not aware of any case law in any given jurisdiction to back that up, but it's a sufficiently well established practice that it's highly unlikely to ever be legally challenged) The PSF has a CLA for CPython because the licensing history and hence the associated licence are rather messy, and not something the PSF can use to accept contributions. Cheers, Nick.

1 0

license for setuptools
by Marinier, Claude 12 Aug '16

12 Aug '16

Good afternoon (well it's afternoon here in the EDT zone), I am in the process of requesting the installation of Python 3 with matplotlib. The company needs to approve licenses but I cannot find the license for setuptools. The description here<https://pypi.python.org/pypi/setuptools> says it uses an MIT license but I cannot confirm this. On github, the file setup.py says the same thing. License :: OSI Approved :: MIT License Could the maintainer please add an explicit license file. I would really like to use matplotlib but will not get approval unless we can confirm the license. Thank you. -- Claude Marinier

10 12

msvc9compiler.py - vcvarsall.bat is living one folder higher - VS90COMNTOOLS
by Dr. Andreas Krueger 10 Aug '16

10 Aug '16

I could not find a github repo, otherwise I would have filed this as an "issue" there. The subfolder "VC" is wrong in msvc9compiler.py - at least on my system (win7-64bit, py2.7.12, anaconda 2.4.1, conda 4.1.11) So in your "msvc9compiler.py" instead of productdir = os.path.join(toolsdir, os.pardir, os.pardir, "VC") it needs to be productdir = os.path.join(toolsdir, os.pardir, os.pardir) Why do I say that? When googling the error message: "DistutilsPlatformError: Unable to find vcvarsall.bat", it is recommended "everywhere" on the web, to download "VCForPython27.msi", Microsoft Visual C++ Compiler for Python 2.7 http://aka.ms/vcpython27 BUT then vcvarsall.bat ends up being in "C:\Users\Andreas\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\vcvarsall.bat" and NOT in "C:\Users\Andreas\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\vcvarsall.bat" where YOUR code is expecting it. Perhaps you actually want to check BOTH places, to keep compatibility with some older versions / different setups? Because I suppose, your code had worked, at some stage in the past. Thanks a lot! Andreas P.S.: I had put some debugging prints to understand your code better, and this is what it outputs: toolsdir= C:\Users\Andreas\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\WinSDK\Bin\ productdir= C:\Users\Andreas\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\WinSDK\Bin\..\..\VC productdir= C:\Users\Andreas\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC vcvarsall= C:\Users\Andreas\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\vcvarsall.bat and that last path is wrong. I could repair it, but only by patching your "msvc9compiler.py": productdir = os.path.join(toolsdir, os.pardir, os.pardir, "VC") --> productdir = os.path.join(toolsdir, os.pardir, os.pardir) now it does find it: toolsdir= C:\Users\Andreas\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\WinSDK\Bin\ productdir= C:\Users\Andreas\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\WinSDK\Bin\..\.. productdir= C:\Users\Andreas\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0 vcvarsall= C:\Users\Andreas\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\vcvarsall.bat

3 3

Python package inquiry
by Meradj Aghdam 09 Aug '16

09 Aug '16

To whom it may concern, Hi, I am new to Python and I am struggling to install Python packages. I have followed the instructions however it does not seem to be working. I am trying to install the package through the Python(Command Line), the package is economics, and when I put python -m pip install Economics It does not work and the error that it is a syntax error. I am using Python 2.7. Would you mind kindly let me know how I can install packages? Your help if very much appreciated, Kind regards, Meradj

3 2