Mailman 3 June 2013 - Distutils-SIG

tox-1.5.0: uses setuptools, whitelisting commands, MIT license
by holger krekel June 22, 2013

June 22, 2013

tox-1.5.0 is a new release of the virtualenv-managing generic Python test runner. It comes with a few fixes and improvements (see below), and is now released under the MIT license -- prior versions used the GPL2. The main change is that tox now by default creates virtualenv's with setuptools, after the merge of distribute (thanks Jason R. Coombs). See docs at: http://tox.testrun.org and install with: pip install -U tox Thanks to Lukasz Balcerzak, Krisztian Fekete for PRs, Armin Ronacher and others for issue reporting, holger 1.5.0 ----------------- - fix issue104: use setuptools by default, instead of distribute, now that setuptools has distribute merged. - make sure test commands are searched first in the virtualenv - re-fix issue2 - add whitelist_externals to be used in ``[testenv*]`` sections, allowing to avoid warnings for commands such as ``make``, used from the commands value. - fix issue97 - allow substitutions to reference from other sections (thanks Krisztian Fekete) - fix issue92 - fix {envsitepackagesdir} to actually work again - show (test) command that is being executed, thanks Lukasz Balcerzak - re-license tox to MIT license - depend on virtualenv-1.9.1 - rename README.txt to README.rst to make bitbucket happier

1 0

devpi-0.9.2: uploading existing archives files
by holger krekel June 22, 2013

June 22, 2013

devpi, the caching pypi server and its optional upload/test/install helper tool, just got a devpi-0.9.2 release. See the full updated docs here: http://doc.devpi.net Apart from some streamlining, there is a new upload option:: devpi upload --from-dir path/to/dir [--only-latest] which uploads existing release files to a devpi index, optionally only the latest versions. This is achieved with the help of ``pkginfo`` extracting PKGINFO files and, for the few where it's missing, using the filename to determine name/version data. Thanks to Anthon van der Neut for his related PRs. See below for a more detailed changelog. best, holger 0.9.2 (compared to 0.9.1) ---------------------------- server: - fix /USER/INDEXNAME root views to contain only latest in-stage packages - make +api calls return bases so that "devpi use" can show them client: - introduce "devpi upload --fromdir" for uploading archives in bulk mode, thanks to Anthon van der Neut for helping with this! (resolved issue5) - improve automatic server handling via "devpi use" - for "devpi server" you now need to specify "--log" to see log lines - make "devpi use" also show base indexes by default - fix issue4: auto-server data stored in non-dot dir

2 1

Heads up: I plan to release buildout 2.2.0 this weekend.
by Jim Fulton June 20, 2013

June 20, 2013

Testing has gone well, but I still anticipate a little excitement. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton

2 2

Buildout 2.2.0b1 is available fort testing
by Jim Fulton June 20, 2013

June 20, 2013

Changes: - Switch dependency from ``distribute 0.6.x`` to ``setuptools 0.7.x``. - Handle both addition and subtraction of elements (+= and -=) on the same key in the same section. Forward-ported from buildout 1.6. - Suppress the useless ``Link to <URL> ***BLOCKED*** by --allow-hosts`` error message being emitted by distribute / setuptools. - Extend distutils script generation to support module docstrings and __future__ imports. - Refactored picked versions logic to make it easier to use for plugins. - Use ``get_win_launcher`` API to find Windows launcher (falling back to ``resource_string`` for ``cli.exe``). - Remove ``data_files`` from ``setup.py``: it was installing ``README.txt`` in current directory during installation (merged from 1.x branch). To try it out, copy the new bootstrap file from: http://downloads.buildout.org/2.2.0b1/bootstrap.py Then run the bootstrap, making sure to include the -t option: python bootstrap.py -t The -t option is necessary to use the non-final buildout release. We'd like to release 2.2 final soon, so your testing is really helpful. Special thanks to Tres Seaver for updating buildout to work with setuptools 0.7 and for reviewing and merging a number of outstanding pull requests. Of course, thanks to the folks to contributed the many other changes in this release. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton

3 2

Binary installer on Windows can't install extension
by Malte Forkel June 19, 2013

June 19, 2013

Hello, I have a problem with an install script in Python 2.7.5 on Windows 7 64-Bit. I have written an install script to register a COM server for a Windows-specific package. I specify the script with the --install-script option to the bdist_wininst command. When I run the installer, the install script fails trying to install an extension: Traceback (most recent call last): ... File "C:\Program Files\Python\lib\site-packages\mx\DateTime\DateTime.py", line 9, in <module> from mxDateTime import * File "C:\Program Files\Python\lib\site-packages\mx\DateTime\mxDateTime\__init__.py", line 13, in <module> raise ImportError, why ImportError: DLL load failed: %1 is not a valid Win32 application. close failed in file object destructor: sys.excepthook is missing lost sys.stderr The last three lines of output are probably caused by a known, unrelated issue (http://bugs.python.org/issue15321). I can run the install script by hand without problems. Importing mx.DateTime in Python works fine as well. I know very litte about Windows internals, but have a guess nevertheless: I checked mx\DateTime\mxDateTime\mxDateTime.pyd with Dependency Walker (depends.exe). It seems, the extension does not find the proper version of MSVCR90.DLL. Instead, it is trying to use a 32-bit version of the DLL that was installed as part of a 32-bit application. The application's directory is included in the user search path (PATH). Obviously, a 64-bit version of the DLL exists and is used by Python itself. What is causing my problem? How can I solve it? Thanks, Malte

4 8

PEP439 and upgrading pip
by Marcus Smith June 18, 2013

June 18, 2013

maybe this was covered before, but I'm looking for clarification on how pip upgrades are to work under PEP439. I see 3 relevant bits right now: 1) "attempts to import pip machinery. If it can then the pip command proceeds as normal" i.e., once it has a pip installed, it doesn't automatically upgrade on subsequent imports. 2) "A bootstrap is used in the place of a the full pip code so that we don't have to bundle pip and also the install tool is upgradeable outside of the regular Python upgrade timeframe and processes" to be clear, what is the "install tool" here? pip? or the bootstrap? 3) "Manual installation of the pip implementation will be supported through the manual download of the wheel file and "pip3 install <downloaded wheel file>. This installation will not perform standard pip installation steps of saving the file to a cache directory or updating any local database of installed files."" I guess this means "manual upgrades" as well? this special logic is to be inside pip itself? or an override of "install" in the bootstrap (that detects when it's a pip wheel)? Marcus

3 8

[issue151] Jerry Regal
by jerry June 16, 2013

June 16, 2013

New submission from jerry: How are you? Jerry Regal ---------- files: unnamed messages: 723 nosy: jerry status: unread title: Jerry Regal Added file: http://bugs.python.org/setuptools/file91/unnamed _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue151> _______________________________________________

1 0

error using easy_install
by Ethan Furman June 16, 2013

June 16, 2013

My setup.py: -- 8< -------------------------------------------------------------- from distutils.core import setup long_desc = open('enum.rst').read() setup( name='stoneleaf.enum', version='1.0.1', url='https://pypi.python.org/pypi/stoneleaf.enum', packages=['enum'], package_dir={'enum':''}, package_data={'enum':['enum.rst', 'enum.pdf', 'test/test_enum.py', 'test/py2_test_enum.py', 'test/py3_test_enum.py']}, license='BSD License', description='Python 3.4 Enum backported to 3.3, 3.2, 3.1, 2.7, 2.6, 2.5, and 2.4', long_description=long_desc, provides=['enum'], author='Ethan Furman', author_email='ethan(a)stoneleaf.us', classifiers=[ 'Development Status :: 5 - Production/Stable', 'Intended Audience :: Developers', 'License :: OSI Approved :: BSD License', 'Programming Language :: Python', 'Topic :: Software Development' ], ) -- 8< -------------------------------------------------------------- Error trying to install it with easy_install after uploading it to PyPI: ethan@hydra:~$ sudo easy_install stoneleaf.enum Searching for stoneleaf.enum Reading http://pypi.python.org/simple/stoneleaf.enum/ Best match: stoneleaf.enum 1.0.1 Downloading http://pypi.python.org/packages/source/s/stoneleaf.enum/stoneleaf.enum-1.0.… Processing stoneleaf.enum-1.0.1.zip Writing /tmp/easy_install-LY_zzX/stoneleaf.enum-1.0.1/setup.cfg Running stoneleaf.enum-1.0.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-LY_zzX/stoneleaf.enum-1.0.1/egg-dist-tmp-IpvhLD error: Setup script exited with error: can't copy 'num.rst': doesn't exist or not a regular file There is no 'num.rst' file in the package -- it should be 'enum.rst'. Any ideas? Is this the right place to post? -- ~Ethan~

2 2

Post-merge setuptools Python 3 single-codebase port available
by Vinay Sajip June 15, 2013

June 15, 2013

Following the setuptools/distribute merge, I've updated my single codebase port of the merged setuptools at [1]. Source of my repo is available at [2] (single-codebase branch). Travis integration has been set up; results are at [3]. Currently, all tests are passing for 2.5, 2.6, 2.7, 3.2, and 3.3. For installation into PEP 405 venvs, a wheel has been set up at [4]. Feedback welcome. Regards, Vinay Sajip [1] https://bitbucket.org/pypa/setuptools/ [2] https://bitbucket.org/vinay.sajip/setuptools/ [3] https://travis-ci.org/vsajip/setuptools/ [4] https://bitbucket.org/vinay.sajip/setuptools/downloads/

2 1

bdist_msi install-script observations
by Malte Forkel June 15, 2013

June 15, 2013

Hello, two things I've noticed when testing an install script with bdist_msi: - The installer requests admin privileges for an installation for all users (on Windows 7), but the install script does not seem to be executed with admin privileges. E.g., execution of win32.com.server.register.RegisterClasses fails with "pywintypes.error: (5, 'RegSetValue', 'Access denied')" - If an error occurrs in the install script, the installer claims "Your system has not been changed" when in fact all files have been installed. My fault, bug, or feature? Thanks, Malte

1 0