Distutils-SIG May 2014

distutils-sig@python.org

45 participants
45 discussions

by Manuel López

Hello Everybody: I am trying to install distribute-0.6.25 in a windows 7 machine. I have python 2.7.3 in 32 bits, although the machine is 64 bits. I installed the 32 bit python version because I want to install ipython and there is no 64 bit builds of the Windows installer for ipython. In any case, upon installing disuitils with python setup.py install I get the following error error: C:\manuel\prog_red\python\distribute-0.6.25\distribute-0.6.25\setuptools\cli-32.exe: No such file or directory Any help will be greatly appeciated. Thanks, Manuel -- Manuel López Mariscal Depto. de Oceanografía Física/CICESE malope(a)cicese.mx

6 years, 9 months

Problem with latest buildout bootstrap on Windows with Python 3.3

by Lele Gaifax

Hi all, I'm facing a problem trying to bootstrap a buildout with its latest bootstrap script under Windows, using Python 3.3. I'm looking for some hint to decide whether the issue is with buildout, Python 3, or with my own installation ... The problem is that executing the bootstrap script I obtain an ImportError on the standard `getopt` module. Digging a bit, I see that ``site.getsitepackages()`` returns a list composed by two elements, ``c:\\Python33`` and ``c:\\Python33\\lib\\site-packages``: effectively even the 3.4 code at http://hg.python.org/cpython/file/bc160f985b7b/Lib/site.py#l312 explicitly puts the plain "prefix" into the list. Then the buildout bootstrap script does something like:: for sitepackage_path in site.getsitepackages(): sys.path[:] = [x for x in sys.path if sitepackage_path not in x] and obviously after that ``sys.path`` does *not* contain any standard library path (which lives under "c:\\Python33\\Lib"), just the current working directory and `c:\\Windows\\system32\\python33.zip`. The code in the bootstrap script seems correct (even if it should probably use something like ``not x.startswith(sitepackage_path)``), what seems strange is that, under Windows, the ``getsitepackages()`` result contains a bare ``c:\\Python33``... for comparison, on my Debian sid I get:: Python 3.3.5 (default, Mar 22 2014, 13:24:53) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import site >>> site.getsitepackages() ['/usr/local/lib/python3.3/dist-packages', '/usr/lib/python3/dist-packages', '/usr/lib/python3.3/dist-packages', '/usr/lib/dist-python'] >>> What is going wrong here? Thanks a lot for any suggestion, ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. lele(a)metapensiero.it | -- Fortunato Depero, 1929.

6 years, 9 months

Re: [Distutils] Metabuild hooks

by Nick Coghlan

On 13 May 2014 08:03, "Paul Moore" <p.f.moore(a)gmail.com> wrote: > The current approach is to solve 90% of the problem by noting that > nearly all projects don't take advantage of any of the (usually > undocumented) flexibility that distutils allows. This has thus far > been a great success, in terms of getting people on board with the new > tools and technologies. The problem is that it does nothing for that > remaining 10%[1] > > We're now at a point where people like MAL, who are in that 10%, are > getting excluded and we don't have a good answer for them. That's a > big problem - particularly as the people in question are quite often > those to whom we owe a lot of the progress that distutils gave us (I > remember the pre-distutils world, and it *SUCKED*). I wish we had an > answer here. I'm particularly worried that some proportion of the 10% > may be complex in-house environments that we'll never hear about till > we break them horribly. But I don't know what we can do. We need to be > able to move forwards, and the lack of encapsulation in distutils > means we will break things when we do. > > Now I'm depressed... Note that this problem is specifically why the metadata 2.0 extension design now has the concept of mandatory extensions - so we can later define an installation hook system (along the lines of RPMs triggers), and have installers that don't understand the relevant extension fall back to installing directly from source. We should make that "fall back to running 'setup.py install' directly if you don't understand a metadata extension in the wheel file" aspect explicit, but either a metabuild system spec or the revision of the wheel spec that adds metadata 2.0 support would likely be the right place for that, rather than having it directly in the metadata 2.0 details (on the other hand, it may also make sense to include as an example use case for the attribute in the PEP 426 explanatory notes). Cheers, Nick. > > Paul > > [1] 95% of all statistics quoted on the internet were made up on the spot. > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG(a)python.org > https://mail.python.org/mailman/listinfo/distutils-sig

6 years, 9 months

PyPI down?

by Wichert Akkerman

I am getting a 503 backend read error (XID: 3216482461) on all PyPI I’m trying. Is there a problem? Wichert.

6 years, 9 months

pip win7 python3.4 32bit behind proxy with no dns, timeout error

by Hicham Mouline

Hello, I am trying this command: pip search --index https://185.31.17.175/pypi --proxy IPofProxyBox:PortNumber packagename DNS is not working on this box. The proxy is a software proxy that I control on the proxy box, that i am running in user mode. Browser(chrome) with these proxy settings works well. I get this error: TimeoutError: [WinError 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond The cme.exe on win7 has this proxy settings too: >>> netsh winhttp show proxy Current WinHTTP proxy settings: Proxy Server(s) : IPofProxyBox:PortNumber Bypass List : (none) Regards, MM

6 years, 9 months

[buildout] New Buildout 2 bootstrap script

by Jim Fulton

I've posted a new buildout 2 and 2.1 bootstrap script: http://downloads.buildout.org/2/bootstrap.py That has the new location of the ez_setup.py script. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton

6 years, 9 months

[buildout] HTTP Error 503 downloading https://bitbucket.org/pypa/setuptools/raw/0.7.2/ez_setup.py

by Chris Withers

Hi All, Seeing lots of Jenkins jobs intermittently failing with this: Traceback (most recent call last): File "bootstrap.py", line 79, in <module> exec(urlopen('https://bitbucket.org/pypa/setuptools/raw/0.7.2/ez_setup.py' File "/usr/local/lib/python2.7/urllib2.py", line 126, in urlopen return _opener.open(url, data, timeout) File "/usr/local/lib/python2.7/urllib2.py", line 400, in open response = meth(req, response) File "/usr/local/lib/python2.7/urllib2.py", line 513, in http_response 'http', request, response, code, msg, hdrs) File "/usr/local/lib/python2.7/urllib2.py", line 438, in error return self._call_chain(*args) File "/usr/local/lib/python2.7/urllib2.py", line 372, in _call_chain result = func(*args) File "/usr/local/lib/python2.7/urllib2.py", line 521, in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) urllib2.HTTPError: HTTP Error 503: SERVICE UNAVAILABLE Anyone else seen similar? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

6 years, 9 months

Windows 8 pkg_resources permissions bug

by Ian Cordasco

Hey all, I searched the issues on the setuptools repository but I couldn't find any that seemed relevant to what a user of Flake8 has run into: https://bitbucket.org/tarek/flake8/issue/142/installation-on-windows-8-perm… It seems that installing something that relies on pkg_resources to load plugins will cause errors on Windows 8. Does anyone have any insight? Is this actually a bug? Are we just using pkg_resources incorrectly? Thanks in advance, Ian

6 years, 9 months

[ANN] stdeb 0.7.1

by Andrew Straw

Hi all, stdeb is a package to produce Debian packages from Python packages. Today I’m announcing release 0.7.1 of stdeb. Highlights since the last publicly announced release (0.6.0): • New command-line commands: pypi-download and pypi-install to directly download and install packages from PyPI, respectively. py2dsc-deb directly creates a .deb file from a source tarball. • New distutils command: install_deb lets you directly install a python package as a standard system package. • Many bugfixes, including the new URL for PyPI. • Automated runs of test suite, thanks to Travis CI. Thanks to many, especially Piotr Ożarowski in this release, for help with stdeb. Changelog: https://github.com/astraw/stdeb/blob/release-0.7.1/CHANGELOG.txt Download: https://pypi.python.org/pypi/stdeb/0.7.1 Development: https://github.com/astraw/stdeb Best regards, Andrew

6 years, 9 months

New Documentation URL for pip and virtualenv

by Donald Stufft

pip and virtualenv have moved their documentation away from http://www.pip-installer.org/ and http://www.virtualenv.org/ to https://pip.pypa.io/ and https://virtualenv.pypa.io/. The new locations are still backed by ReadTheDocs however they are fronted by Fastly and have enforced TLS. The old documentation URLs will redirect to the new locations indefinitely so all existing links should continue to work. This is part of a larger effort to consolidate all of the PyPA related work under one domain. Currently this includes: * https://pip.pypa.io/ * https://virtualenv.pypa.io/ * https://warehouse.pypa.io/ * https://bootstrap.pypa.io/ ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

6 years, 9 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG May 2014