Mailman 3 May 2013 - Distutils-SIG

zc.buildout-2.1.0 is broken on Windows with distribute-0.6.39
by Guy Rozendorn 13 May '13

13 May '13

distribute-0.6.39 introduces exe wrappers for arm, and there's one cli.exe and gui.exe: 09:30:12 ⮀ guyr-air ⮀ /tmp ⮀ find distribute-0.6.39 -name '*exe' distribute-0.6.39/setuptools/cli-32.exe distribute-0.6.39/setuptools/cli-64.exe distribute-0.6.39/setuptools/cli-arm-32.exe distribute-0.6.39/setuptools/gui-32.exe distribute-0.6.39/setuptools/gui-64.exe distribute-0.6.39/setuptools/gui-arm-32.exe 09:30:15 ⮀ guyr-air ⮀ /tmp ⮀ find distribute-0.6.38 -name '*exe' distribute-0.6.38/setuptools/cli-32.exe distribute-0.6.38/setuptools/cli-64.exe distribute-0.6.38/setuptools/cli.exe distribute-0.6.38/setuptools/gui-32.exe distribute-0.6.38/setuptools/gui-64.exe distribute-0.6.38/setuptools/gui.exe This causes bootstrap.py to fail: Administrator@host-ci46 ~/projector $ python bootstrap.py Creating directory 'C:\\Cygwin\\home\\Administrator\\projector\\bin'. Creating directory 'C:\\Cygwin\\home\\Administrator\\projector\\parts'. Creating directory 'C:\\Cygwin\\home\\Administrator\\projector\\eggs'. Creating directory 'C:\\Cygwin\\home\\Administrator\\projector\\develop-eggs'. While: Bootstrapping. An internal error occured due to a bug in either zc.buildout or in a recipe being used: Traceback (most recent call last): File "C:\Cygwin\home\Administrator\python\lib\site-packages\zc.buildout-2.1.0-py2.7.egg\zc\buildout\buildout.py", line 1923, in main getattr(buildout, command)(args) File "C:\Cygwin\home\Administrator\python\lib\site-packages\zc.buildout-2.1.0-py2.7.egg\zc\buildout\buildout.py", line 404, in bootstrap or ''), File "C:\Cygwin\home\Administrator\python\lib\site-packages\zc.buildout-2.1.0-py2.7.egg\zc\buildout\easy_install.py", line 960, in scripts initialization, rpsetup) File "C:\Cygwin\home\Administrator\python\lib\site-packages\zc.buildout-2.1.0-py2.7.egg\zc\buildout\easy_install.py", line 1064, in _script return _create_script(contents, dest) File "C:\Cygwin\home\Administrator\python\lib\site-packages\zc.buildout-2.1.0-py2.7.egg\zc\buildout\easy_install.py", line 1107, in _create_script new_data = pkg_resources.resource_string('setuptools', 'cli.exe') File "C:\Cygwin\home\Administrator\python\lib\site-packages\distribute-0.6.39-py2.7.egg\pkg_resources.py", line 926, in resource_string self, resource_name File "C:\Cygwin\home\Administrator\python\lib\site-packages\distribute-0.6.39-py2.7.egg\pkg_resources.py", line 1199, in get_resource_string return self._get(self._fn(self.module_path, resource_name)) File "C:\Cygwin\home\Administrator\python\lib\site-packages\distribute-0.6.39-py2.7.egg\pkg_resources.py", line 1326, in _get stream = open(path, 'rb') IOError: [Errno 2] No such file or directory: 'C:\\Cygwin\\home\\Administrator\\python\\lib\\site-packages\\distribute-0.6.39-py2.7.egg\\setuptools\\cli.exe'

1 1

HTTPS and certificate check update for distribute ?
by M.-A. Lemburg 05 May '13

05 May '13

The latest pip supports HTTPS URLs and certificate checks (according to the change log). Will there be a release of distribute that implements the same changes ? The current 0.6.36 still defaults to the HTTP PyPI address and doesn't do certificate checks. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 25 2013) >>> Python Projects, Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2013-04-17: Released eGenix mx Base 3.2.6 ... http://egenix.com/go43 ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

4 7

Re: [Distutils] distribute-0.6.37
by Tarek Ziadé 05 May '13

05 May '13

On 5/5/13 10:57 AM, Guy Rozendorn wrote: > Hey Tarek, > > easy_install on Windows is broken in 0.6.37, see https://bitbucket.org/tarek/distribute/issue/371/launcher-manifest-is-not-i… > Waiting for your approval to release 0.6.38 with a fix for this issue > > Thanks, > Guy > > Hi Guy Jason & other folks are maintaining Distribute now. I cc'ed him and distutils@ Thanks Tarek -- Tarek Ziadé · http://ziade.org · @tarek_ziade

1 0

PEP 439 and default install locations (was Re: distil 0.1.1 released)
by Nick Coghlan 04 May '13

04 May '13

On 4 May 2013 09:03, "Carl Meyer" <carl(a)oddbird.net> wrote: > > Hi Nick > > On 05/03/2013 12:14 PM, Nick Coghlan wrote: > > I would also be relatively happy for pip to refuse the temptation to > > guess if run globally and require an explicit --user or --system > > whenever it is run outside a virtual environment. However, I think it's > > better to make the typical "pip install whatever" work for most > > unprivileged users without requiring elevated privileges. > > > > I agree the proposed exception for root doesn't make sense so I withdraw > > that idea, even though installing things into root's home directory is a > > little strange. > > > > As far as Debian's dist-packages setup goes, that's their workaround for > > this misfeature of the current Python packaging ecosystem. > > IMO requiring either --user or --system is bad UI (we should have a sane > default). Defaulting to --user is tempting, but also a bad idea, both > because of the massive adjustment that it would require from existing > users, and because it does the wrong thing in many cases where there are > multiple Pythons compiled on the system. > > I think the best solution to this problem is quite easily implemented > and non-intrusive: an improved error message when pip finds that it > lacks permission to install to site-packages. This error message could > recommend --user and/or virtualenv, could warn quite strongly against > installing to this location unless you really know what you are doing, etc. That sounds eminently reasonable. > Also, I think that for the specific situation of a Linux distribution's > "system Python" (which, as Donald has pointed out, is only one mode of > Python installation out of many), Debian's solution is better than just > a workaround, it is conceptually more or less the Right Thing: separate > distro-managed Python code from user-managed Python code, without > preventing independent installation of Python-installation-wide code by > the user. > > (Though some aspects of the implementation of Debian's solution are > sub-optimal and have required ugly workarounds in pip. It would be > better if multiple site-packages were a first-class concept in Python's > own site.py so Debian's solution could be implemented via configuration > rather than patches.) Agreed, blessing something like Debian's solution sounds like a better idea than changing pip's default installation location. To provide that blessing, I think PEP 439 should be expanded to explicitly cover this aspect (there's another subtlety, in that it may be desirable for distro packages to be available when running with -S - I'm not sure how Debian currently handle that). Essentially, my goal is to have a clearly defined, consistent, cross-distro-and-platform shadowing behaviour for cases where you install a Python software distribution from a system package manager *and* through pip. The current situation, where the system tools and the Python specific tools tread on each other's toes at the filesystem layer (unless you change the default Python path, as Debian does) isn't appropriate for something we are going to ship as part of the standard Python toolkit. (Coincidentally, this may lead to my CPython bootstrapping changes becoming packaging related!) Cheers, Nick. > > Carl > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG(a)python.org > http://mail.python.org/mailman/listinfo/distutils-sig

2 1

distil 0.1.1 released
by Vinay Sajip 03 May '13

03 May '13

I've released version 0.1.1 of distil, downloadable from [1]. It's based on distlib 0.1.2. The other changes are as follows: * Added "distil init" to support creating an initial version of package.json metadata, which can then be added to during development. * Added "distil link" to support "editable" installations, similar to pip install -e local_dir. * Take into account pre-confirmation (-y) during uninstallation when dists that are no longer needed are found. These are now removed automatically when -y is specified. * Fixed error in setting up SSL certificate verification, and adjusted PyPI URLs to be https:// where specified as http:// in metadata. Successful SSL verification is now logged. * Added --local-dists option to allow local wheels and sdists to be used for installation. * Fixed a bug in the handling of local archives (e.g. those returned through a configured DirectoryLocator). Local archives shouldn’t be deleted after unpacking. * Added --python-tags argument to distil package when building wheels to configure the tags for the built wheel. * Added --no-unpack option to distil download. * Fixed problem with rollback on error caused by not recording SHARED and RECORD correctly. * Fixed bug in writing entry points (EXPORTS) file. * Use of 2to3 now defaults to True when run under 3.x. * Fixed bug when run in venvs which caused e.g. dist-packages to be used instead of site-packages. * Improved error message when run with Python 2.5 (not supported, but this is now clear from the error message). Your feedback will be gratefully received! Regards, Vinay Sajip [1] https://bitbucket.org/vinay.sajip/docs-distil/downloads/distil.py

7 22