Mailman 3 January 2017 - Distutils-SIG

Virtalenv and setuptools [was: latest setuptools appears to require six in a breaking way]
by Paul Moore Jan. 25, 2017

Jan. 25, 2017

On 25 January 2017 at 17:20, Chris Withers <chris(a)simplistix.co.uk> wrote: > Right, so what's the recommended one-step way to set up a virtualenv now in > Py 2.6-3.6? This is the point I would consider most significant here. Virtualenv is deliberately built to allow use offline - pip, wheel and setuptools are bundled so that it's possible to create a virtualenv without needing Internet access. This change to setuptools will, if I understand it, break that expectation. While it's not a common scenario, I think it's something that should be considered. Going forward, I see a number of options for virtualenv: 1. Bundle all of setuptools' dependencies as well. 2. Drop the "no internet required" constraint - if we do this, it may be reasonable to only bundle pip, and get latest versions of everything else from PyPI. 3. Drop auto-installing setuptools (it's not needed unless you're installing from sdist, and it's only a "pip install setuptools" away for people who need it). 4. Document the changed behaviour by saying that no internet is required as long as you use --no-setuptools. Thoughts, anyone? Is the situation common enough to warrant anything other than (4)? It used to be for me, when pip didn't cache downloads and I had a secured proxy to deal with, but now I'd be OK with (4). Paul

3 7

Enquire for python
by ali refaee Jan. 25, 2017

Jan. 25, 2017

Dear Sir/Madam I’m beginner in python, how can I get python modules? when run some function such as (import numpy as np) message ImportError: No module named numpy another ex import matplotlib.pyplot as plt ImportError: No module named matplotlib.pyplot how we install modules? where are the modules? can I get modules to run python? Sent from Windows Mail

2 1

recommended strategy for missing development tools
by Robin Becker Jan. 25, 2017

Jan. 25, 2017

A reportlab user says his pip install fails to create an importable C extension. He said "The platform is Mac OS X 10.11.6, aka "El Capitan". Pip didn't complain" which is probably true since the extension is not required for reportlab's main usage. I tried to reproduce on OS X 10.10.5, but my machine has xcode installed and the extension was correctly produced. I don't have any code in setup.py to prevent compilation; is there a way to alert users to the non-build of the extension(s). -- Robin Becker

3 3

latest setuptools appears to require six in a breaking way
by Chris Withers Jan. 25, 2017

Jan. 25, 2017

Hi All, Anyone else seen this? |File "/home/travis/virtualenv/python2.6.9/lib/python2.6/site-packages/setuptools/__init__.py", line 10, in <module> from six.moves import filter, map ImportError: No module named six.moves| Started happening in my nightly builds on travis after the 34.0.2 release of setuptools. I've filed an issue here since I suspect it isn't just me: https://github.com/pypa/setuptools/issues/945 cheers, Chris

1 0

Compiling and installing C executable in setup.py
by sashk Jan. 21, 2017

Jan. 21, 2017

Hello, I've got a python package which requires to install C executable, which will need to go into proper place, i.e. same place where scripts would go ($VIRTUAL_ENV/bin, /usr/local/bin, etc). What would be the correct way to implement this? I found couple examples, but they work only when using pip to install the package, but fail when I try to use python setup.py install: they will build the executable, but will not install it during the "install bdist_egg" stage. Regards, -sashk

1 0

Limit package installation to a specific Python version
by Lele Gaifax Jan. 20, 2017

Jan. 20, 2017

Hi all, do installers like pip and conda consult trove classifiers, or more generally is there a way to "mark" a package published on PyPI as installable only in a Python 3 environment? An user proposed[1] to change the classifiers of a package to get that result, so I tried looking at pip and setuptools sources, but didn't find evidence of that. I see both use python_requires[2] in their setup that seem closer to the goal, but again, is that actually honored by pip and/or other installers? Thanks for any hint, ciao, lele. [1] https://github.com/python-rapidjson/python-rapidjson/pull/47 [2] https://www.python.org/dev/peps/pep-0345/#requires-python -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. lele(a)metapensiero.it | -- Fortunato Depero, 1929.

3 3

Has anyone looked at bug 29225?
by Elvis Stansvik Jan. 20, 2017

Jan. 20, 2017

Hi distutils folks, Just wanted to ask if anyone has had time to look at my http://bugs.python.org/issue29225 ? It's my first bug report _and_ first patch for Python, so it's quite possible I screwed something up. Or people are just busy :) Cheers, Elvis

2 4

Re: [Distutils] RFC 2: PEP 541 - Package Index Name Retention
by Chris Rose Jan. 17, 2017

Jan. 17, 2017

(copied from an email I erroneously sent to python-ideas@) I want to address one gap in the PEP regarding reclaiming abandoned names: Version reuse. The problem with reusing names is that existing applications or installations that reference the old one, unless they pin the version name precisely. Even in that case, I foresee issues with version collision, especially if the abandoned project was well-versioned in the same model (semver or otherwise) that the new project uses. I'm deeply concerned by the idea of installer code suddenly picking up a new project... with possibly different dependencies on its own, either with old or clashing versions. I recognize it's going to be rare, but these incidents will definitely impact the repeatability of builds depending on PyPi. I think the criteria for reuse of a name must include usage limits; if the package is being downloaded on a steady basis by accounts that can't be shown to belong to known integration systems, reuse should not be allowed. -- Chris R. ====== Not to be taken literally, internally, or seriously. Twitter: http://twitter.com/offby1

5 8

How to specify dependencies in Python
by Thomas Güttler Jan. 17, 2017

Jan. 17, 2017

I came across a python library which has docs, which start like this: {{{ Quickstart Include foolib in your requirements.txt file. }}} AFAIK dependencies should be specified via `install_requires` in `setup.py`. Should I talk to the maintainer of the library and create a pull-request for the docs? Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/

6 13

Re: [Distutils] RFC: PEP 541 - Package Index Name Retention
by Nick Coghlan Jan. 16, 2017

Jan. 16, 2017

On 17 Jan 2017 09:20, "Dariusz Suchojad" <dsuch(a)zato.io> wrote: On 16/01/17 23:10, Robert Collins wrote: > So, this proposition didn't really make sense to me. Folk like Linux > distros will want the source, and you don't need to upload wheels :- > setup.py could quite reasonably limit itself to software installation, vs > configuration. Plenty of pip installable packages are not entirely ready to > use after pip installation. Hi Robert, I'm not clear if this was meant in reply to my email? I'm genuinely perplexed. I just don't know how to relate it to the suggestion I made in this message: https://mail.python.org/pipermail/distutils-sig/2017-January/030015.html There are several sub-threads in this discussion and I'm not quite sure what you mean. Robert's referring to the fact that publishing a project sdist on PyPI can be quite helpful to redistributors, even if "pip install zato" just installs some helper libraries (or nothing at all) rather than a full Zato instance. Publishing at least a stub package with a README and setup.py that says "Zato is not pip installable, see <url> for details" would also provide a better experience for prospective users than a plain 404, provide the PyPI maintainers with a clear explanation of how the namespace entry is being used, and the project with download metadata that gives an indication of how often this mistake is being made, and hence whether or not it's an installation method that might be worth supporting (even if it's just a shim around a "docker pull" command). Cheers, Nick.

2 1