Cross-posting to distutils-sig:
As a prerequisite to adding useful finer-grained installations to
setuptools & wheel, I propose adding install_paths.json as a metadata
file within the egg-info and dist-info directories, initially
containing only the current paths as a key - value mappping, for
example it might contain the following keys:
These are the existing paths present as properties on the
distutils/setuptools install command. Later, when we add a finer
grained install scheme, those paths would also land in the new
In setuptools (non-wheel installations from setup.py) it's very easy
to add an additional "egg_info.writers" entry point to create this
file. Wheel installers would need to be modified to generate this
Recording the existing paths would solve a current problem with
customized installs e.g. "python setup.py install
--install-lib=/custom/path" ; the custom lib path is not recorded
anywhere, making it difficult to locate the library.
In C, libraries and headers are not really installed to standard
locations. There are conventions that differ between operating systems
and distributions. That is why the pkg-config command exists, which
reads a similar key : path mapping from files in /usr/share/pkgconfig/
or from PKG_CONFIG_PATH. This mapping would serve a similar purpose
for Python distributions that might need to locate more of their
installed files besides just those installed on PYTHONPATH.
Straw man API to use the recorded paths:
The pkg_resources API could be extended to support interpolating these
paths. You would need to pass a Requirement, not an importable name
from sys.modules, to locate a particular .egg-info or .dist-info.
Under the hood pkg_resources would use
Distribution._get_metadata('_install_paths.json') to read the install
scheme used for that particular distribution.
Gives an example of:
"extras": ["warmup", "c-accelerators"]
But I am not sure how to map the current setuptools example below to PEP-426:
'warmup': ['softcushions', 'barheater'],
'c-accelerators': ['cython', 'barheater'],
Would we expect multiple build_requires that list barheater, with
separate extra lines, in PEP-426?
Like so (adjusted to be all run-requires as extra setup-requires
aren't a thing in setuptools today):
"extras": ["warmup", "c-accelerators"]
"requires": ["cython", "barheater"],
Since build_requires is a key, I'm more than a little confused here.
Seems like the extra has to be part of the key, or we're going to be
Robert Collins <rbtcollins(a)hp.com>
HP Converged Cloud
New submission from Blake VandeMerwe:
On line 152 `if type(value) != type()` will break if value is a tuple instead of a list, which messes up the lgoic from 155-159
To duplicate, in setup.py:
name = 'test setup',
classifiers = (
'Development Status :: 3 - Alpha',
Traceback (most recent call last):
File "setup.py", line 47, in <module>
test_suite = 'tests'
File "C:\Python34\lib\distutils\core.py", line 148, in setup
File "C:\Python34\lib\distutils\dist.py", line 955, in run_commands
File "C:\Python34\lib\distutils\dist.py", line 974, in run_command
File "C:\Python34\lib\distutils\command\upload.py", line 65, in run
self.upload_file(command, pyversion, filename)
File "C:\Python34\lib\distutils\command\upload.py", line 163, in upload_file
TypeError: 'str' does not support the buffer interface
title: commands.upload.upload_file breaks when iterable 'value' is not of type tuple
Setuptools tracker <setuptools(a)bugs.python.org>
I try to maintain several built and installed versions of Python,
currently 2.6, 2.7, 3.2, 3.3, 3.4 and 3.5alpha, all built from the
tips of their respective branches in Mercurial.
What's the correct/best way to keep pip up-to-date for all those
versions? 2.7, 3.4 and 3.5 have ensurepip, but I think that just makes
sure you have pip, not that there is a version associated with a
specific version of Python, right? Do I just download the latest
tarball and run "PY setup.py install" for each version of PY?
I want to install google-api-python-client using pip. I can see it when I
search from the command line:
% pip-2.7 search google | egrep google-api
google-api-python-client - Google API Client Library for Python
google-apitools - client libraries for humans
google-api-python-client-py3 - Google API Client Library for Python (python
google-apis-client-generator - Google Apis Client Generator
I can see it in PyPI:
When I try to install it, pip denies any knowledge of the package:
% pip-2.7 install --user google-api-python-client
Cannot fetch index base URL http://pypi.python.org/simple/
Could not find any downloads that satisfy the requirement
No distributions at all found for google-api-python-client
Storing complete log in /Users/skip/.pip/pip.log
I can visit http://pypi.python.org/simple/ and see that
google-api-python-client is one of the links. Looking at pip.log I see that
it's somehow translating "http" into "https":
Could not fetch URL
http://pypi.python.org/simple/google-api-python-client/: <urlopen error
unknown url type: https>
Am I missing something?
Can't login with Google and with LaunchPad.
Google breakage was predictable, but LaunchPad
What is the status of PyPI maintenance. A year or
two ago patches were not welcome, because
people were busy with warehouse.