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
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).
I’m beginner in python, how can I get python modules?
when run some function
such as (import numpy as np)
ImportError: No module named numpy
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
A reportlab user says his pip install fails to create an importable C extension.
"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
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).
Anyone else seen this?
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
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.
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 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 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,
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.
Hi distutils folks,
Just wanted to ask if anyone has had time to look at my
? 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 :)
(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
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.
Not to be taken literally, internally, or seriously.
I came across a python library which has docs, which start like this:
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?
Thomas Guettler http://www.thomas-guettler.de/
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
> use after pip installation.
I'm not clear if this was meant in reply to my email? I'm genuinely
I just don't know how to relate it to the suggestion I made in this message:
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
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).