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
No such file or directory
Any help will be greatly appeciated. Thanks,
Manuel López Mariscal
Depto. de Oceanografía Física/CICESE
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
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
What is going wrong here?
Thanks a lot for any suggestion,
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.
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%
> 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).
>  95% of all statistics quoted on the internet were made up on the spot.
> Distutils-SIG maillist - Distutils-SIG(a)python.org
Hello, I am trying this command:
pip search --index https://188.8.131.52/pypi --proxy
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)
Seeing lots of Jenkins jobs intermittently failing with this:
Traceback (most recent call last):
File "bootstrap.py", line 79, in <module>
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
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
raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
urllib2.HTTPError: HTTP Error 503: SERVICE UNAVAILABLE
Anyone else seen similar?
Simplistix - Content Management, Batch Processing & Python Consulting
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:
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
Thanks in advance,
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.