A couple of buglets I've noticed while using picky in anger:
1. pip freeze doesn't include a line for pip itself, why is that?
2. pip freeze doesn't include packages provided by the standard libary
(ie: wsgiref), even if they're explicitly specified in requirements.txt.
What's the pip developers view of both of the above? Is this still the
right forum to discuss these things?
I have the following directory structure:
If I zip this into myegg.egg and run "python myegg.egg", that runs the
top-level __main__.py. If I run "python setup.py bdist_egg" and run the
resulting egg, I get "/usr/bin/python: can't find '__main__.py'" in the
egg. That is correct: according to "unzip -l" __main__.py is not there.
How do I get it included?
Or more to the point, how do I make that egg directly executable? --
note that I want it to run a script that isn't in any of the bundled
packages (but imports from them).
(centos 6 with python 2.6 and python-setuptools-0.6.10 and centos 7 with
python 2.7 and python-setuptools-0.9.8)
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
These two sections:
...imply that downloading packages with pip 7.x+ should create an
offline cached egg.
(pip_cache)tweedledee:virtualenvs chris$ pip --version
pip 7.0.3 from
/Users/chris/virtualenvs/pip_cache/lib/python2.7/site-packages (python 2.7)
(pip_cache)tweedledee:virtualenvs chris$ pip install xlwt
Downloading xlwt-1.0.0-py2.py3-none-any.whl (140kB)
100% |████████████████████████████████| 143kB 730kB/s
Installing collected packages: xlwt
Successfully installed xlwt-1.0.0
(pip_cache)tweedledee:virtualenvs chris$ ls ~/Library/Caches/pip/
(pip_cache)tweedledee:virtualenvs chris$ find ~/Library/Caches/pip/
Nope, no wheel cache there.
What am I missing? Are those docs just plain wrong?
Some packages have docs like this:
pip install foo
Maybe I am too new in the python packaging world, but
for my eyes calling easy_install looks deprecated.
My goal is to make the python world more friendly for newcomers.
Are there still reason to use easy_install and not pip?
I would like to make the docs more readable and remove
the word "or" from them. Things should be straight forward
for newcomers and experts know how to help themselves.
What do you think?
For people loving details: this mail checks if there is a general consensus. It does not
matter which packages I refer to.
Thomas Guettler http://www.thomas-guettler.de/
So the pip wheel caching feature has promoted a few latent problems
into the limelight.
One is that many wheels projects built are not actually as compatible
as thought. https://github.com/pypa/pip/issues/2882
One is that wheels don't support writing datafiles outside their
And the one I want to talk about is that we don't generate
sufficiently good platform markers on Linux.
That bug describes the scenario of using a wheel cache shared across
multiple Linux ABIs - e.g. LXC containers with a bind mounted home
dir, or NFS on a cluster. pip 7's implicit wheel cache triggers this
situation for people.
The OP has suggested that being able to control the platform tag that
pip a) looks for and b) instructs wheel to use would let them avoid
issues in this situation without having to solve the general problem
of 'the universe of Linuxs can't agree on anything'.
e.g, in each context they could set a /etc/pip.conf containing
wheel_platform = contextname
and then pip would use that and instruct built wheels to use that.
Further, they not that it can be used to e.g. describe other local
policies like 'I want hardened C builds' that are not inferrable from
context at all today.
But since this affects pip *and* wheel, we're bringing it here for discussion.
I'm in favour of it - it fits the existing wheel spec; its opt-in,
non-intrusive and solves a real, present problem. [just not the 'how
do we get these damn things into PyPI, yet].
Robert Collins <rbtcollins(a)hp.com>
HP Converged Cloud
It looks like the defaults for ccompiler.executables that are set in
compiler-specific sublcasses like UnixCCompiler are always overridden by
customize_compiler in sysconfig.py. For example, in UnixCcompiler the value
for executables['compiler'] is ["cc"], but this will never be used because
comtomize_compiler invariably grabs the compiler value out of the Python
Makefile and uses that. Should customize_compiler be reorganized a bit so that
defaults are actually used if customize_compiler comes up empty-handed for
Next, it looks like customize_compiler is really a method of UnixCcompiler
disguised as an independent function. Would it make sense for Ccompiler to
have an abstract method, "customize", and to move the current
customize_compiler function into UnixCcompiler?
On the topic of include directories, would it make sense to add a
"sysinclude_dirs" option to the Extension class in order separate out the two
different uses that include_dirs currently plays in setup.py scripts?
-----BEGIN PGP SIGNED MESSAGE-----
On 06/04/2015 03:43 AM, Suresh V. wrote:
> Could it be your umask? Just wondering...
Nope. This issue only affects the 'jython' environment -- all other tox
environments run fine.
Tres Seaver +1 540-429-0999 tseaver(a)palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
-----END PGP SIGNATURE-----
I'm trying to write a new `setup.py` file for an extension module to
wrap a C library (https://github.com/cvxgrp/scs).
The current `setup.py` file imports numpy. I'm trying to delay that
import statement until setuptools has a chance to install numpy if
it's not already installed. I'm trying to do that with this bit of
from setuptools.command.build_ext import build_ext as _build_ext
# Prevent numpy from thinking it is still in its setup process:
__builtins__.__NUMPY_SETUP__ = False
self.include_dirs += ext['include_dirs'] + [numpy.get_include()]
Running `python setup.py install` seems to work fine on my OSX
machine, but when I run `pip install .` in the directory with
`setup.py`, I get a clang error that it can't find one of the header
Any idea why that would be happening? Could it have anything to do
with the relative path I'm giving for the include directories?
Also, I had trouble finding good documentation on subclassing
build_ext. Does anyone know if setting self.include_dirs overwrites or
appends to the include_dirs attribute of an Extension object defined
later in setup.py?
For the curious, my current attempt at setup.py is
original can be found in the same directory.
More generally, since I'm new to python packaging, I'm not sure how
well or correctly I've written my `setup.py` file. Any feedback on
doing things correctly would be appreciated.