distribute-0.6.39 introduces exe wrappers for arm, and there's one cli.exe
09:30:12 ⮀ guyr-air ⮀ /tmp ⮀ find distribute-0.6.39 -name '*exe'
09:30:15 ⮀ guyr-air ⮀ /tmp ⮀ find distribute-0.6.38 -name '*exe'
This causes bootstrap.py to fail:
$ 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'.
An internal error occured due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
line 1923, in main
line 404, in bootstrap
line 960, in scripts
line 1064, in _script
return _create_script(contents, dest)
line 1107, in _create_script
new_data = pkg_resources.resource_string('setuptools', 'cli.exe')
line 926, in resource_string
line 1199, in get_resource_string
return self._get(self._fn(self.module_path, resource_name))
line 1326, in _get
stream = open(path, 'rb')
IOError: [Errno 2] No such file or directory:
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.
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
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,
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
> Distutils-SIG maillist - Distutils-SIG(a)python.org
I've released version 0.1.1 of distil, downloadable from . 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
* 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
* 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!