Mailman 3 December 2013 - Distutils-SIG

distlib 0.1.6 released on PyPI
by Vinay Sajip 31 Dec '13

31 Dec '13

I've just released version 0.1.6 of distlib on PyPI [1]. 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: Updated the binary launcher executables, because the wrong variant of these was shipped with the previous release. A more detailed change log is available at [2]. Please try it out, and if you find any problems or have any suggestions for improvements, please give some feedback using the issue tracker! [3] Regards, Vinay Sajip [1] https://pypi.python.org/pypi/distlib/0.1.6 [2] http://pythonhosted.org/distlib/overview.html#change-log-for-distlib [3] https://bitbucket.org/pypa/distlib/issues/new

1 0

Re: [Distutils] Platform specific destinations in wheel files?
by Nick Coghlan 28 Dec '13

28 Dec '13

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. Cheers, Nick. 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

1 0

Platform specific destinations in wheel files?
by Nick Coghlan 28 Dec '13

28 Dec '13

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 being defined. 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. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

5 14

classifiers not up to date on testpypi
by Antoine Pitrou 22 Dec '13

22 Dec '13

Registering pathlib to https://testpypi.python.org/pypi Server response (400): Invalid classifier "Programming Language :: Python :: 3.4"

1 0

Source distribution fails when packages have a setup.cfg file and are checked out from Perforce
by Philippe Muller 16 Dec '13

16 Dec '13

Hello, 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 Writing foo-0.4.0/setup.cfg error: foo-0.4.0/setup.cfg: Permission denied That's happening because Perforce forces files to be read-only when not "Perforce opened". 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 ? Thanks, Philippe Muller

1 0

distlib 0.1.5 released on PyPI
by Vinay Sajip 15 Dec '13

15 Dec '13

I've just released version 0.1.5 of distlib on PyPI [1]. 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 anti-virus products. A more detailed change log is available at [2]. Please try it out, and if you find any problems or have any suggestions for improvements, please give some feedback using the issue tracker! [3] Regards, Vinay Sajip [1] https://pypi.python.org/pypi/distlib/0.1.5 [2] http://pythonhosted.org/distlib/overview.html#change-log-for-distlib [3] https://bitbucket.org/pypa/distlib/issues/new

1 0

problems upload docs to pythonhosted.org with setuptools 2.0
by Chris Withers 14 Dec '13

14 Dec '13

Hi All, 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 running upload_docs 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. Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

2 2

Encoding error installing my own package from PyPI
by Lele Gaifax 13 Dec '13

13 Dec '13

Hi all, 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[1] 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)) Downloading metapensiero.sqlalchemy.proxy-1.9.6.tar.gz Running setup.py egg_info for package metapensiero.sqlalchemy.proxy Cleaning up... Exception: 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 req_to_install.assert_source_matches_version() 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 return self.pkg_info()['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)[0] 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 command... 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, ciao, lele. [1] https://bitbucket.org/lele/metapensiero.sqlalchemy.proxy/src/608bf172973986… -- 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.

3 4

Scripts in installed wheel RECORD
by Bohuslav Kabrda 12 Dec '13

12 Dec '13

Hey all, 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? Thanks. -- Regards, Bohuslav "Slavek" Kabrda.

2 2

Setuptools 2.0 Released
by Jason R. Coombs 10 Dec '13

10 Dec '13

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. Jason PyPA

5 4

Distutils-SIG December 2013