Mailman 3 July 2015 - Distutils-SIG

400 Client Error: Binary wheel for an unsupported platform
by Antoine Pitrou 10 Jul '15

10 Jul '15

Hello, I'm having the following errors when trying to upload a wheel to PyPI. (yes, the version number is off - but that's besides the point here, I think): $ twine upload dist/llvmlite-0.0.0-py2.py3-none-linux_x86_64.whl /home/antoine/.local/lib/python3.4/site-packages/pkginfo/installed.py:53: UserWarning: No PKG-INFO found for package: pkginfo warnings.warn('No PKG-INFO found for package: %s' % self.package_name) Uploading distributions to https://pypi.python.org/pypi Uploading llvmlite-0.0.0-py2.py3-none-linux_x86_64.whl HTTPError: 400 Client Error: Binary wheel for an unsupported platform $ twine upload dist/llvmlite-0.0.0-py3-none-linux_x86_64.whl /home/antoine/.local/lib/python3.4/site-packages/pkginfo/installed.py:53: UserWarning: No PKG-INFO found for package: pkginfo warnings.warn('No PKG-INFO found for package: %s' % self.package_name) Uploading distributions to https://pypi.python.org/pypi Uploading llvmlite-0.0.0-py3-none-linux_x86_64.whl HTTPError: 400 Client Error: Binary wheel for an unsupported platform Thanks Antoine.

10 28

devpi-{server-2.2.2,web-2.4.0,client-2.3.0} releases
by holger krekel 09 Jul '15

09 Jul '15

We just released devpi-server-2.2.2, devpi-web-2.4.0 and devpi-client-2.3.0, core parts of the private pypi package management and testing system. Among the highlights are support for distributed testing with "devpi test --detox", new status pages at "/+status" for replica and master sites and support for configuring upload formats when running "devpi upload". None of the changes require an export/import cycle on the server side if you used devpi-server-2.2.X before. However, please read the respective changelog entries below for some notes and potentially backward-incompatible changes. See the home page for docs and tutorials: http://doc.devpi.net have fun, Holger Krekel and Florian Schulze contracting: http://merlinux.eu server-2.2.2 ------------ - make replica thread more robust by catching more exceptions - Remove duplicates in plugin version info - track timestamps for event processing and replication and expose in /+status - implement devpiweb_get_status_info hook for devpi-web >= 2.4.0 status messages - UPGRADE NOTE: if devpi-web is installed, you have to request ``application/json`` for ``/+status``, or you might get a html page. - address issue246: refuse uploading release files if they do not contain the version that was transferred with the metadata of the upload request. - fix issue248: prevent change of index type after creation web-2.4.0 --------- - macros.pt: Add autofocus attribute to search field - macros.pt and style.css: Moved "How to search?" to the right of the search button and adjusted width of search field accordingly. - fix issue244: server status info - added support for status message plugin hook ``devpiweb_get_status_info`` - macros.pt: added macros ``status`` and ``statusbadge`` and placed them below the search field. - added status.pt: shows server status information - toxresults.pt: fix missing closing ``div`` tag. client-2.3.0 ------------ - fix issue247: possible password leakage to log in devpi-client - new experimental "-d|--detox" option to run tests via the "detox" distributed testing tool instead of "tox" which runs test environments one by one. - address issue246: make sure we use vcs-export also for building docs (and respect --no-vcs for all building activity) - address issue246: copy VCS repo dir to temporary upload dir to help with setuptools_scm. Warn if VCS other than hg/git are used because we don't copy the repo in that case for now and thus cause incompatibility with setuptools_scm. - (new,experimental) read a "[devpi:upload]" section from a setup.cfg file with a "formats" setting that will be taken if no "--formats" option is specified to "devpi upload". This allows to specify the default artefacts that should be created along with a project's setup.cfg file. Also you can use a ``no-vcs = True`` setting to induce the ``--no-vcs`` option.

2 1

picky 0.8 released!
by Chris Withers 09 Jul '15

09 Jul '15

Hi All, I'm please to announce the first release of picky, a tool for checking versions of packages used pip are as specified in their requirements files. I wrote this tool because it's all too easy to have a requirements.txt file for you project that you think covers all the resources you're using, only to find you've been dragging in extra packages unknowingly, and you now have different versions of those in development and production, causing lots of debugging misery! Using picky is as easy as: $ pip install picky $ echo 'picky==0.8' >> requirements.txt $ picky If you want to update your requirements.txt based on your current environment: $ picky --update Full docs are at http://picky.readthedocs.org/en/latest/. Source control and issue trackers are at https://github.com/Simplistix/picky. <https://github.com/Simplistix/picky> Any problems, please ask here or mail me direct! cheers, Chris

2 1

Phantom release/file and now can't upload
by James Bennett 08 Jul '15

08 Jul '15

Earlier tonight I was trying to upload a new version (1.1) of https://pypi.python.org/pypi/django-contact-form Initially tried 'setup.py sdist' followed by 'twine upload -s' of the resulting tarball. Twine reported success, but no new release or file appeared on PyPI. Tried 'setup.py sdist upload'. That reported success, but no new release or file appeared on PyPI. I tried quite a lot of things after that and kept getting reports of success... and no new release or file on PyPI. I even went and copy/pasted a sample from the distutils documentation using 'setup.py sdist upload -r' to force PyPI just in case it was somehow using the wrong index. Eventually some combination of things must have at least partly worked, because information about a 1.1 release of django-contact-form appeared on PyPI... except the file itself still did not appear, and any attempt to upload returned: HTTPError: 400 Client Error: This filename has previously been used, you should use a different version. I am absolutely stumped as to what's going on. I've tried deleting and re-creating the 1.1 release to re-upload, but I'm stuck at being able to create only an empty release with no file, since PyPI will not allow the file to be uploaded. While I try to track down what happened, who has the power to override PyPI's disallowed filename restriction for this? As far as I can tell, the file was *never* listed on PyPI and so could not have been downloaded by anyone, and after struggling with this for a few hours I'm not at all in the mood to bump versions just to get PyPI to cooperate.

2 3

ANN: distlib 0.2.1 released on PyPI
by Vinay Sajip 07 Jul '15

07 Jul '15

I've just released version 0.2.1 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: Fixed issue #58: Return a Distribution instance or None from locate(). Fixed issue #59: Skipped special keys when looking for versions. Improved behaviour of PyPIJSONLocator to be analogous to that of other locators. Added resource iterator functionality. Fixed issue #71: Updated launchers to decode shebangs using UTF-8. This allows non-ASCII pathnames to be correctly handled. Ensured that the executable written to shebangs is normcased. Changed ScriptMaker to work better under Jython. Changed the mode setting method to work better under Jython. Changed get_executable() to return a normcased value. Handled multiple-architecture wheel filenames correctly. 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.2.1 [2] https://goo.gl/K5Spsp [3] https://bitbucket.org/pypa/distlib/issues/new

1 0

markers, <= and python 2.7.10
by Robert Collins 03 Jul '15

03 Jul '15

So - 426 markers specify string comparisons only. This is now broken in the wild :) We need to figure out: - what comparisons we should allow (e.g. - versions, or tuples, or ?) - what the migration strategy for early adopters looks like - do we change the meaning of python_version - do we define a new symbol name - do we break existing markers, or force some type gymnastics (e.g. casting the user side of the marker to a sequence of components)? https://bitbucket.org/pypa/setuptools/commits/e01e9a77fad5 https://github.com/pypa/pip/issues/2943 -Rob -- Robert Collins <rbtcollins(a)hp.com> Distinguished Technologist HP Converged Cloud

3 5

New buildout release needed
by Reinout van Rees 01 Jul '15

01 Jul '15

Hi, I've done quite a lot of work on buildout in the last two or three weeks. Merging pull requests and also submitting a couple of my own. If you look at the list of pull requests (https://github.com/buildout/buildout/pulls) you'll see a bunch that need further work ("doc or tests needed") and a handful of "plus or minus" pull requests, dealing with plus-minus stuff regarding sections. I don't use that much and I haven't looked at those yet. Perhaps someone else wants to? I've also set up travis-ci.org caching so that the builds on travis run two to three times faster. And I've fixed several issues dealing with non-ascii filenames. Apparently, if you install pyramid (for instance), buildout will fail to run. Apparently it is enough to install something like mr.bob to break buildout totally. It is now fixed in https://github.com/buildout/buildout/pull/250 There are two things that need doing now that I cannot do: - Review https://github.com/buildout/buildout/pull/248 with a number of bootstrap fixes. The fixes themselves aren't controversial, I think (adding a version, for instance). The one thing I want feedback on is that buildout now deletes the contents of the develop-eggs/ directory when it bootstraps. This helps a lot with faulty left-over egg-links in corner cases. The old osc.recipe.sysegg recipe for instance used to reliably wreak my buildouts (syseggrecipe is the replacement that does the right thing). Zapping the develop-eggs contents on bootstrap helps solve several problems. In my case, I really want this change to go in as it might mean the difference between my company using buildout or not... I'm getting tired of saying "oh, remove the develop-eggs directory contents". - Make a new zc.buildout, zc.recipe.egg and bootstrap.py release. See issue https://github.com/buildout/buildout/issues/249 . Reinout -- Reinout van Rees http://reinout.vanrees.org/ reinout(a)vanrees.org http://www.nelen-schuurmans.nl/ "Learning history by destroying artifacts is a time-honored atrocity"

4 6

picky 0.9.2 released!
by Chris Withers 01 Jul '15

01 Jul '15

Hi All, I'm please to announce another release of picky, a tool for checking versions of packages used pip are as specified in their requirements files. I wrote this tool because it's all too easy to have a requirements.txt file for you project that you think covers all the resources you're using, only to find you've been dragging in extra packages unknowingly, and you now have different versions of those in development and production, causing lots of debugging misery! Using picky is as easy as: $ pip install picky $ echo 'picky==0.9.2' >> requirements.txt $ picky If you want to update your requirements.txt based on your current environment: $ picky --update This release has the following major changes since the last announced release: * Python 3 support * Fixed handling of package ‘extras’ in pip output and specifications. * Fixed handling of arbitrary equality clauses in pip output and specifications. * Correct the dependency specification of|argparse|so it only occurs on Python 2.6 * Check to see if|pip|takes|--disable-pip-version-check|before using it. Full docs are at http://picky.readthedocs.org/en/latest/. Source control and issue trackers are at https://github.com/Simplistix/picky. <https://github.com/Simplistix/picky> Any problems, please ask here or mail me direct! cheers, Chris PS: While I sympathise with the intentions of the pip version check, I do feel that not enough consideration has been given to safe, scripted use of pip. Of course, people who do that and don't have control what version of pip their users may choose, like me, are doomed anyway now, so I guess no point crying over spilled milk?

1 0

Inconsistent package build with stdeb?
by Oz Tiram 01 Jul '15

01 Jul '15

Hi Everyone, I am trying to build a Debian package a Python library that includes shared object from boost. When building on machine the files and the proper links are included, here is an example: I am building the package like this: (machine1) $ python setup.py --command-packages=stdeb.command bdist_deb ... Now I check that the symbolic links and the objects are still there: (machine1) $ dpkg -c deb_dist/python-dataextract_8200.14.0819.2015-1_all.deb | grep date -rw-r--r-- root/root 95000 2014-08-20 05:20 ./usr/share/pyshared/dataextract/lib/libboost_date_time.so.1.53.0 rwxrwxrwx root/root 0 2015-07-01 10:46 ./usr/lib/python2.7/dist-packages/dataextract/lib/libboost_date_time.so -> libboost_date_time.so.1.53.0 rwxrwxrwx root/root 0 2015-07-01 10:46 ./usr/lib/python2.7/dist-packages/dataextract/lib/libboost_date_time.so.1.53.0 -> ../../../../../share/pyshared/dataextract/lib/libboost_date_time.so.1.53.0 rwxrwxrwx root/root 0 2015-07-01 10:46 ./usr/lib/pyshared/python2.7/dataextract/lib/libboost_date_time.so -> ../../../../python2.7/dist-packages/dataextract/lib/libboost_date_time.so Now one the other machine with exact same version of python-stdeb I issue the same build command, with a different result: (machine2) $ dpkg -c deb_dist/python-dataextract_8200.14.0819.2015-1_all.deb | grep date -rw-r--r-- root/root 95000 2014-08-20 05:20 ./usr/lib/python2.7/dist-packages/dataextract/lib/libboost_date_time.so rwxrwxrwx root/root 0 2015-07-01 10:32 ./usr/lib/pyshared/python2.7/dataextract/lib/libboost_date_time.so -> ../../../../python2.7/dist-packages/dataextract/lib/libboost_date_time.so As you can see the versioned files `libboost_date_time.so.1.53.0` are missing and I am quite puzzled why. I must also say that, this machine is the exception. I have other machines where the package builds properly. Can someone please provide a clue? Thanks, Oz --- Imagine there's no countries it isn't hard to do Nothing to kill or die for And no religion too Imagine all the people Living life in peace

1 0