-----BEGIN PGP SIGNED MESSAGE-----
3 out of 8 PyPI mirror are out of date or not available.
This is not good for the PyPI reputation.
Of course mirror can have problems for a while but the
maintainers should feel in charge of maintaining
and checking their mirrors regularly.
I propose that an obvious unmaintained mirror should be removed
(temporarily) if it has not been updated after N days. Right now
N = 50 and N = 69 which is hardly acceptable.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
I'm trying to move the distlib and pylauncher repositories to the PyPA
account on BitBucket. I'm getting Internal Server Errors with both repos and
have logged an issue on BitBucket. This is just to let you know that the
transfer will hopefully happen soon, so some BitBucket links might not work
during the transition.
Python ZIP Application Support -
Title: Improving Python ZIP Application Support
Author: Daniel Holth <dholth(a)gmail.com>
Type: Standards Track
Created: 30 March 2013
Post-History: 30 March 2013
Improving Python ZIP Application Support
Python has had the ability to execute directories or ZIP-format
archives as scripts since version 2.6. When invoked with a zip file or
directory as its first argument the interpreter adds that directory to
sys.path and executes the __main__ module. These archives provide a
great way to publish software that needs to be distributed as a single
file script but is complex enough to need to be written as a
collection of modules.
This feature is not as popular as it should be for two reasons: a)
users haven’t heard of it because it wasn’t mentioned in earlier
versions of Python 2.6 “What’s New” document, and b) Windows users
don’t have a file extension (other than .py) to associate with the
This PEP proposes to fix these problems by re-publicising the feature,
defining the .pyz and .pyzw extensions as “Python ZIP applications”
and “Windowed Python Zip Applications”, and providing some simple
tooling to manage the format.
A New Python ZIP Application Extension
The Python 3.4 installer will associate .pyz and .pyzw “Python ZIP
Applications” with itself so they can be executed by the Windows
launcher. A .pyz archive is a console application and a .pyzw archive
is a windowed application. This indicates whether the console should
appear when running the app.
Why not use .zip or .py? Users expect a .zip file would be opened with
an archive tool, and users expect .py to be opened with a text editor.
Both would be confusing for this use case.
For UNIX users, .pyz applications should be prefixed with a #! line
pointing to the correct Python interpreter and an optional
# This is a Python application stored in a ZIP archive.
(binary contents of archive)
As background, ZIP archives are defined with a footer containing
relative offsets from the end of the file. They remain valid when
concatenated to the end of any other file. This feature is completely
standard and is how self-extracting ZIP archives and the bdist_wininst
installer format work.
Minimal Tooling: The pyzaa Module
This PEP also proposes including a simple application for working with
Python ZIP Archives: The Python Zip Application Archiver “pyzaa”
(rhymes with “huzzah” or “pizza”). “pyzaa” can archive or extract
these files, compile bytecode, and can write the __main__ module if it
is not present.
python -m pyzaa (pack | unpack | compile)
python -m pyzaa pack [-o path/name] [-m module.submodule:callable]
[-c] [-w] [-p interpreter] directory:
ZIP the contents of directory as directory.pyz or [-w]
directory.pyzw. Adds the executable flag to the archive.
-c compile .pyc files and add them to the archive
-p interpreter include #!interpreter as the first line of the archive
-o path/name archive is written to path/name.pyz[w] instead of
dirname. The extension is added if not specified.
-m module.submodule:callable __main__.py is written as “import
pyzaa pack will warn if the directory contains C extensions or if
it doesn’t contain __main__.py.
python -m pyzaa unpack arcname.pyz[w]
The archive is unpacked into a directory [arcname]
python -m pyzaa compile arcname.pyz[w]
The Python files in arcname.pyz[w] are compiled and appended to
the ZIP file.
 http://bugs.python.org/issue1739468 “Allow interpreter to execute
a zip file”
This document has been placed into the public domain.
(Second try to distutils-sig instead of catalog-sig)
I'd like to request that PyPi add a classifier for the web framework
"Framework :: Bottle"
I have a plugin ready to upload for the Bottle framework as well as a
couple more in the works.
It seems distribute_setup.py installs specific version of distribute
(hardcoded inside the file). However get-pip.py installs the latest
version. Why doesn't distribute_setup.py install the latest version of
Hope attendees had a great time at PyCon 2013! We certainly enjoyed
presenting to you our lightning talk on securing PyPI with TUF
Since then, we have been busy improving TUF and implementing machinery
to automatically secure PyPI with TUF:
You may also have noticed that the root metadata for our prototype
mirror of PyPI+TUF expired yesterday. This aligns nicely with our plan
for switching our hand-maintained PyPI+TUF mirror with the automatic
one. We expect to have it ready very soon, and until then, we certainly
welcome your first impressions on our automation. You could try it on
your machine right away!
Finally, we are working continuously on improving TUF, especially on
ensuring that the metadata scales with data. We welcome your feedback on
these issues and more (https://github.com/akonst/tuf/issues?state=open).
I see that the video for the Directions in Packaging panel is up on
pyvideo.org, but I'm curious as to what happened in the mini-summit. Is
someone going to write up what was discussed / if anything was agreed (beyond
just descriptions of the various projects)? If it's already been posted
somewhere, I'd be grateful for the link.
Thanks & regards,
To help bring things under a common umbrella project, I've just moved the
PyPI code from Martin's personal repository to the PyPA one. Thanks Donald
for enabling that move, and thanks to Martin for the initial move to hg way
I've moved the links for bug tracking to the new repository but the old
bugs in Martin's repository and those in the sf.net tracker are still
there. Not that there's many tuits(round) being spent on working on them...
I just did some work moving bandersnatch a bit further towards a
The recent changesets contain changes that require some manual
adjustments for existing installations:
* run `bin/python bootstrap.py` and `bin/buildout` again because I
switched to buildout 2
* you need to update your cronjobs because the commands have been
renamed to 'bin/bandersnatch mirror' and 'bin/bandersnatch update-stats'
* check the default config file: it now includes the parameters for
I think I don't need any further breakage for mirror administrators in
the near future and will be able to make a PIP-installable release in
the next days.
If you find any further bugs, please tell me on bitbucket.
Also, if enough people start gittipping me, then I'll start adding more
mirrors on international locations as I can afford them.
good news: I have cut a 1.0 release for "bandersnatch", the PEP381
client that I started as an overhaul of "pep381client" at PyCon 2013.
Here's the news:
* I decided to use a "requirements.txt" to support PIP-based environments.
* Markus Zappke Gründemann noticed that I was missing the actual
license text and provided me with a pull request.
* Overhauled README, hopefully a bit easier to read.
The next step on my agenda is to get all the existing public mirror
operators on board so that we hopefully will see more "green bar"
moments when visiting pypi-mirrors.org. Who can help?
 There is some integration magic to automatically generate the
requirements.txt, have it available for different releases on
bitbucket, etc. See "buildout.py" and "release.py" in the package code.
Not for the faint of heart. I also added a jenkins job that verifies
the requirements.txt, installs the sdist package and runs tests from