On 28 December 2013 21:36, Vinay Sajip <vinay_sajip(a)yahoo.co.uk> wrote:
> I don't have anything actually written, though all the information is available in the JSON for individual releases under the "source/data-files" key. I will look at writing a simple scanner which looks at all the unique directories declared by PyPI dists. This should be faster when run locally on the server than a script which fetches the JSON via HTTP. Give me a bit of time, and I'll post what I find.
Data driven design? What madness is this? :)
Good idea Paul, and thanks for looking into it Vinay.
P.S. That reminds me, I should redo the PyPI version compatibility
numbers for the latest PEP 440 draft - making pytz relatively easy to
convert was the main gain, but I suspect the overall compatibility
percentage will improve a little bit regardless.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
With the Python 3.4 feature freeze behind us, I've started looking at
doing a new update of the draft metadata 2.0 docs. Vaguely related to
that are the recent discussions about being able to publish an FHS
compliant daemon like cobblerd as a wheel file - using Python specific
formats to define the layout of full applications, not just libraries.
Currently, all of the paths defined in sysconfig schemes aim to be
platform neutral. However, this means that some platform specific
concepts can't easily be handled by the wheel format - the "data"
scheme can sort of handle it, but it isn't particularly intuitive, and
doesn't inherently reflect the platform dependent nature of the layout
I'd generally been resisting the idea of supporting this (since I
favour interoperating with system packaging tools where appropriate
over attempting to replace them entirely), but in this case I'm
starting to think it may be necessary to support these layouts in the
next version of the wheel format in order to *also* support automated
conversion of upstream projects to policy compliant system packages.
As a reminder, here are the currently defined Python specific
directories relevant to wheel files:
platlib: directory for site-specific, platform-specific files.
purelib: directory for site-specific, non-platform-specific files.
include: directory for non-platform-specific header files.
platinclude: directory for platform-specific header files.
And these are the generic directories that aren't necessarily Python specific:
scripts: directory for script files.
data: directory for data files.
This is still only a half-baked idea at this point, but I'm currently
leaning towards keeping the "<name>.data" sysconfig subdirectories in
the wheel format cross platform (and somewhat Python specific), and
adding a new "<name>.app" subdirectory in parallel.
A wheel that had content in "app" would be inherently platform
specific - you wouldn't be permitted to use the new directory in a
cross-platform wheel file. The defined subdirectories of app would
also be platform specific.
All POSIX systems would at least support the "fhs" subdirectory. For a
system install, this would map to "/", for a virtualenv install it
would map to the root of the virtualenv and for a user install it
would map to "~/.local".
I'm not sure what other subdirectories would be appropriate for
Windows or Mac OS X, although I expect being able to install into
Program Files and Application Data would be interesting for Windows
apps, and into an application folder for Mac OS X.
It's really the potential for FHS support that drives my interest in
the idea, but if we're going to do something like this at all, it
shouldn't be POSIX specific.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
My code is versionned using Perforce, and when creating a source
distribution, I get this error :
$ python setup.py sdist
copying setup.cfg -> foo-0.4.0
error: foo-0.4.0/setup.cfg: Permission denied
That's happening because Perforce forces files to be read-only when not
If I do a "p4 open setup.cfg" before creating the source distribution, the
setup.cfg file will be writable, so will its copy, and the source
distribution is created without any issue.
I currently use a more hackish workaround :
chmod +w setup.cfg ; python setup.py sdist ; chmod -w setup.cfg
But that's ugly. Does anyone know a cleaner way to bypass this issue ?
I've just released version 0.1.5 of distlib on PyPI . For newcomers,
distlib is a library of packaging functionality which is intended to be
usable as the basis for third-party packaging tools.
The main changes in this release are as follows:
Used dummy_threading when threading isn’t available.
Used uncompressed Windows executable launchers, because the
compressed ones cause false positive warnings with some
A more detailed change log is available at .
Please try it out, and if you find any problems or have any suggestions for
improvements, please give some feedback using the issue tracker! 
I'm attempting to upload docs for a new release of my package to
pythonhosted.org but I get:
$ bin/docpy setup.py upload_docs --upload-dir=docs/_build/html
Submitting documentation to http://pypi.python.org/pypi
Upload failed (400): Form data is not correctly encoded in UTF-8
My docs are all ascii as far as I know.
I'm using setuptools 2.0 on Python 2.7.3.
Downgrading to setuptools 1.4.2 fixed the problem.
Simplistix - Content Management, Batch Processing & Python Consulting
for the first time I'm trying to use PyPI to distribute one of my
packages, and I'm having encoding problems with the package metadata
when I install it in a Python 3.3 environment using pip 1.4.1.
I tried to google around, but didn't find any definitive solution.
The package setup.py builds the long_description reading and
concatenating the content of two files, respectively README.rst and
CHANGES.rst, both encoded in UTF-8.
A first attempt used a plain open() call to read the files failed and I
thought to understand the reason, as CHANGES.rst effectively contains a
few non-ascii characters. I then used codecs.open() with an explicit
utf-8 encoding, but that too fails, although in a different place:
Downloading/unpacking metapensiero.sqlalchemy.proxy==1.9.6 (from -r requirements.txt (line 15))
Running setup.py egg_info for package metapensiero.sqlalchemy.proxy
Traceback (most recent call last):
File "/opt/python333/lib/python3.3/site-packages/pip/basecommand.py", line 134, in main
status = self.run(options, args)
File "/opt/python333/lib/python3.3/site-packages/pip/commands/install.py", line 236, in run
requirement_set.prepare_files(finder, force_root_egg_info=self.bundle, bundle=self.bundle)
File "/opt/python333/lib/python3.3/site-packages/pip/req.py", line 1139, in prepare_files
File "/opt/python333/lib/python3.3/site-packages/pip/req.py", line 394, in assert_source_matches_version
version = self.installed_version
File "/opt/python333/lib/python3.3/site-packages/pip/req.py", line 390, in installed_version
File "/opt/python333/lib/python3.3/site-packages/pip/req.py", line 357, in pkg_info
data = self.egg_info_data('PKG-INFO')
File "/opt/python333/lib/python3.3/site-packages/pip/req.py", line 297, in egg_info_data
data = fp.read()
File "/opt/python333/lib/python3.3/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 3072: ordinal not in range(128)
and this time I cannot see a way out, as egg_info_data() does
fp = open(filename, 'r')
data = fp.read()
to read PKG-INFO content, that AFAICT was encoded in utf-8 by the sdist
So the question is: how can I solve the issue? Should I make sure that
all the meta data information is plain ASCII (which of course I can do
quite easily), or am I doing something wrong?
Thanks in advance 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.
so I noticed a strange thing in RECORD of an installed wheel:
When a wheel that contains file "foo-1.data/scripts/spam" is installed, "spam" gets copied to a proper dir (e.g. /usr/bin) and the whole "foo-1.data" directory is deleted. A line with the new location is added to RECORD, but the old line is not deleted, so the file is listed twice in the RECORD file.
This seems to be wrong, since the original file doesn't exist any more, so "foo-1.data/scripts/spam" should be deleted from the RECORD (applies to all all files in "foo-1.data").
PEP 427 doesn't mention this situation, so I'm not sure - is this expected?
Bohuslav "Slavek" Kabrda.
The PyPA is pleased to announce the Setuptools 2.0 release.
This backward-incompatible release drops support for Python 2.4 and Python 2.5, but is otherwise compatible with 1.x releases.
The 1.x series will continue to be supported for bug and security fixes for the foreseeable future. This means that any systems with older versions of Python should install "setuptools<2dev" or use the legacy bootstrap script, available at https://bitbucket.org/pypa/setuptools/raw/bootstrap-py24/ez_setup.py for Python 2.4 and Python 2.5 users. That link is also published in the README as install instructions.
Please report any emergent issues at https://bitbucket.org/pypa/setuptools/issues.