Mailman 3 December 2014 - Distutils-SIG

PEP440: >1.7 vs >=1.7
by Marcus Smith Dec. 29, 2014

Dec. 29, 2014

I'm starting a new thread to state cleanly what my current question/concern is... per PEP440 as I understand it: - for ">1.7", "1.7" means roughly the "1.7 series" or "1.7*" - for ">=1.7", "1.7" means literally "1.7" (with zero-padding as needed) While I understand the motivation for the "series" conception of 1.7 to deal with prereleases, the resulting inconsistency in meaning for "1.7" is what concerns me. It's odd . Can someone make it not seem odd for "1.7 to change meanings just because you switch between >= and >? And for anyone who wants to say that "1.7" also means the "1.7 series" for >=, note that 1.7 prereleases do not satisfy >=1.7 Would a solution be to make >= also use the series concept?, i.e. make pre-releases satisfy >=1.7 Marcus

5 23

setuptools-8.4.zip?
by Jim Fulton Dec. 28, 2014

Dec. 28, 2014

Bootstrapping buildout is failing because buildout uses https://bootstrap.pypa.io/ez_setup.py which tried to download: https://pypi.python.org/packages/source/s/setuptools/setuptools-8.4.zip which doesn't exist. Did someone forget to upload setuptools-8.4.zip? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton

3 3

Can zc.buildout use same comparison operator for versions as setup.py
by William Zhang Dec. 28, 2014

Dec. 28, 2014

Hello Can zc.buildout use same comparison operator for versions as setup.py? *buildout* It use "show-picked-versions" for print verison https://pypi.python.org/pypi/zc.buildout/2.3.1#easier-reporting-and-managin… [versions] buildout-versions = 1.2 setuptools = 0.6c11 zc.buildout = 1.5.0 *setup.py* It use install_requires for handle package's version https://docs.python.org/2/distutils/setupscript.html#relationships-between-… install_requires=[ 'django == 1.4', 'South == 0.7.5', ] Is there any way for "show-picked-versions" print version be used by setup.py install_requires? Thanks William -------------------- This is the life!

4 3

PEP440: foo-X.Y.Z does not satisfy "foo>X.Y"?
by Marcus Smith Dec. 28, 2014

Dec. 28, 2014

In PEP440, foo-X.Y.Z does not satisfy the specifier "foo>X.Y" (although it satisfies "foo>=X.Y") for example, foo-1.7.2 will not satisfy "foo>1.7", but it will satisfy "foo>=1.7" for '>' and '<', PEP440 states that they are "interpreted as implying the prefix based version exclusion clause != V.*" the rationale from Donald for this is explained here: https://bitbucket.org/pypa/setuptools/issue/301/101-in-requirementparse-foo… in brief, this was done to avoid pre-releases (i.e. something like "foo-1.7a1") satisfying "foo<1.7". It seems to me we've just traded one confusion for another, and this seems worse (to me at least, although I'm trying to let it sink in) 1.7.2 is greater than 1.7, and the specifiers should honor that. It's hard to accept otherwise. Yes, it's true in the past, when people would get a pre-release installed (for example 1.7a1), when they really wanted something in the 1.6.X series, that was also confusing. But now that pip now excludes pre-releases by default, it seems that confusion is mostly solved practically speaking, so why solve it (and create a new confusion)? Marcus

8 30

PEP440 examples missing operator?
by Marcus Smith Dec. 23, 2014

Dec. 23, 2014

the first 3 examples here are confusing. https://www.python.org/dev/peps/pep-0440/#examples there's no comparison operator?

3 6

New User: stdeb, depends not appearing in control file
by Geoff Clements Dec. 23, 2014

Dec. 23, 2014

Hi! I just started using stdeb but have run into a problem which I can't solve. Just for background, so you know at what level to aim replies, I'm a long-time programmer, over 30 years in fact. I make much of what I do available to others but I've only just got around to packaging, so I know absolutely nothing about how to package code (but I'm learning!). I'm using stdeb 0.8.2 installed via pypi because the Ubuntu repos are so hopelessly out of date. I'm building a package for python3 only and uploading to an Ubuntu ppa which I have done but with the following problems: Here's my stdeb.cfg file: [DEFAULT] Depends: libav-tools (>= 6:11), lsdvd (>= 0.17), mplayer2 (>= 2.0), python3- pyqt4 (>= 4.11), python3-pyudev (>= 0.16) XS-Python-Version: >= 3.4 MIME-Desktop-Files: share/ravenc.desktop Suite: utopic Section: universe/video Now here is the control file in the source package that is produced (minus the package description, slightly redacted): Source: ravenc Maintainer: Geoff Clements <e-mail address> Section: universe/video Priority: optional Build-Depends: python3-setuptools, python3-all, debhelper (>= 7.4.3) Standards-Version: 3.9.1 X-Python-Version: >= 3.4 Package: python3-ravenc Architecture: all Depends: ${misc:Depends}, ${python3:Depends} =========== The problem here is that the dependencies have not been carried across to the control file. In addition, when I try to build a binary package I get this warning: dpkg-gencontrol: warning: Depends field of package python3-ravenc: unknown substitution variable ${python3:Depends} This also appears in the build log if a submit the source packages to Ubuntu to include in my ppa. -- Geoff

1 0

Release: pip 6.0 and virtualenv 12.0
by Donald Stufft Dec. 23, 2014

Dec. 23, 2014

I'm happy to announce the release of pip 6.0 and virtualenv 12.0. A High level overview of what this brings: * PEP 440 is fully implemented now and pip will use specifiers and the version selection logic as specified there. * HTTP access will now be cached by default in pip, speeding up repeated downloads of the same file automatically. * Randomized and secure build directories are used by default in most situations. * Accessing an insecure origin (Invalid HTTPS or HTTP) by default is now deprecated. For HTTP this will continue to work in pip 6.0 but raise a warning and for HTTPS this will not work. You may use --trusted-host example.com to re-enable this on a per-host basis. * Added per-virtualenv and a machine global configuration file, as well as support platform standard directories for configuration. * Support environment markers inside of a requirements file. * Support environment markers inside of a setuptools extra. * Automatically retry failed HTTP requests. * Greatly reduce the verbosity of the pip command by default. * Updated virtualenv to have setuptools 8.2.1 and pip 6.0 bundled. * Many many bugfixes and smaller changes. As always please file any issues with either https://github.com/pypa/pip/issues or https://github.com/pypa/virtualenv/issues. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

3 3

Amend PEP 440 regarding timestamp based version identifiers and packaging
by Marcos Klein Dec. 19, 2014

Dec. 19, 2014

I have two update requests for PEP 440. Could PEP 440 date-based version identifier examples be extend to include full timestamp version identifiers? The version identifiers I use in a continuous integration build are derived from ISO8601 time stamps. YearMonthDay "." HourMinuteSecond (UTC) ex. date -u +'%Y%m%d.%H%M%S' This version identifier format has the peculiar aspect of having a number of leading 0s in the version segment when a package is created at the beginning of a new day. 20141218.000018 I just want to make sure any test cases include this version identifier format. This leads me to my second request. Could the effects of normalized version identifiers be clarified when it comes to package builds? The normalization section in PEP 440 only seems to discuss the use of normalization in parsing and processing of the version identifier. I was quite surprised when my package build for the above version identifier became the following under setuptools 8: dated_release-20141218.18-p27-none-any.whl Previous releases of setuptools would build: dated_release-20141218.000018-p27-any.whl This is jarring as it is an unexpected interpretation of PEP 440. It is the classic pointer argument. I want to call it THIS, but it really is THAT. -- Marcos Klein

3 2

Amend PEP 440 with Wider Feedback on Release Candidates
by Donald Stufft Dec. 18, 2014

Dec. 18, 2014

I’ve had a number of people complain that PEP 440 normalizes a release candidate as 1.0c1 instead of 1.0rc1. Do we want to ammend the PEP to switch the normalization around so that it normalizes 1.0c1 to 1.0rc1? This probably matches what people expect better in general? It wouldn't have any effect on sort order or the like, it would just change which form is preferred. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

4 8

[ANN]: distlib 0.2.0 released on PyPI
by Vinay Sajip Dec. 17, 2014

Dec. 17, 2014

I've just released version 0.2.0 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 match_hostname to use the latest Python implementation. Updates to better support PEP 426 / PEP 440. You can now provide interpreter arguments in shebang lines written by distlib. Removed reference to __PYVENV_LAUNCHER__ (relevant to OS X only). 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.0 [2] http://pythonhosted.org/distlib/overview.html#change-log-for-distlib [3] https://bitbucket.org/pypa/distlib/issues/new

1 0