pypa / setuptools Goto Github PK
View Code? Open in Web Editor NEWOfficial project repository for the Setuptools build system
Home Page: https://pypi.org/project/setuptools/
License: MIT License
Official project repository for the Setuptools build system
Home Page: https://pypi.org/project/setuptools/
License: MIT License
Originally reported by: atodorov (Bitbucket: atodorov, GitHub: atodorov)
Hi guys,
I'm not sure if this is a bug but it seems awkward to have Windows executables in a source release which I install on Linux:
setuptools/cli-arm-32.exe : PE32 executable (console) Unknown processor type 0x1c4, for MS Windows
setuptools/gui-arm-32.exe : PE32 executable (console) Unknown processor type 0x1c4, for MS Windows
setuptools/cli-64.exe : PE32+ executable (console) x86-64, for MS Windows
setuptools/cli-32.exe : PE32 executable (console) Intel 80386, for MS Windows
setuptools/gui-32.exe : PE32 executable (GUI) Intel 80386, for MS Windows
setuptools/gui-64.exe : PE32+ executable (GUI) x86-64, for MS Windows
For more info see (ADD-ON INFO button):
http://www.dif.io/updates/distribute-0.6.10/distribute-0.6.43/17481/
Originally reported by: notnoop (Bitbucket: notnoop, GitHub: notnoop)
Setuptools 0.9.1 direct download (https://pypi.python.org/packages/source/s/setuptools/setuptools-0.9.1.tar.gz taken from https://pypi.python.org/pypi/setuptools/0.9.1) link doesn't work anymore.
That causes pip install to fail as well:
(venv2)ubuntu@box6:~$ pip install --upgrade setuptools
Downloading/unpacking setuptools from https://pypi.python.org/packages/source/s/setuptools/setuptools-0.9.1.tar.gz#md5=7068dcbd9ea44139f5abeb65cb916f15
HTTP error 404 while getting https://pypi.python.org/packages/source/s/setuptools/setuptools-0.9.1.tar.gz#md5=7068dcbd9ea44139f5abeb65cb916f15
Could not install requirement setuptools from https://pypi.python.org/packages/source/s/setuptools/setuptools-0.9.1.tar.gz#md5=7068dcbd9ea44139f5abeb65cb916f15 because of error HTTP Error 404: Not Found
Could not install requirement setuptools from https://pypi.python.org/packages/source/s/setuptools/setuptools-0.9.1.tar.gz#md5=7068dcbd9ea44139f5abeb65cb916f15 because of HTTP error HTTP Error 404: Not Found for URL https://pypi.python.org/packages/source/s/setuptools/setuptools-0.9.1.tar.gz#md5=7068dcbd9ea44139f5abeb65cb916f15
Storing complete log in /home/ubuntu/.pip/pip.log
Originally reported by: apollo13 (Bitbucket: apollo13, GitHub: apollo13)
I'd like to suggest to remove easy_install from setuptools and (if wanted) into a separate project. The reasoning is simple: setuptools shouldn't bother with retrieving packages etc, it should concentrate on installing stuff. This would make the setuptools package smaller (yes, that's somewhat of a poor argument), does allow for independent releases and in general would remove some unused stuff if setuptools is just used as a library like via pip.
Originally reported by: jaraco (Bitbucket: jaraco, GitHub: jaraco)
When attempting to install packages from a custom cheeseshop (chishop), the latest setuptools doesn't handle blank md5 values well.
Best match: nose 1.1.2
Downloading http://yfiles.example.com/dists/nose-1.1.2.tar.gz#md5=
Traceback (most recent call last):
File "setup.py", line 159, in <module>
setup(**setup_params)
File "/usr/lib/python2.7/distutils/core.py", line 152, in setup
dist.run_commands()
File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
self.run_command(cmd)
File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File "build/bdist.linux-x86_64/egg/setuptools/command/develop.py", line 27, in run
File "build/bdist.linux-x86_64/egg/setuptools/command/develop.py", line 129, in install_for_development
File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 706, in process_distribution
File "build/bdist.linux-x86_64/egg/pkg_resources.py", line 618, in resolve
File "build/bdist.linux-x86_64/egg/pkg_resources.py", line 862, in best_match
File "build/bdist.linux-x86_64/egg/pkg_resources.py", line 874, in obtain
File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 623, in easy_install
File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 653, in install_item
File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 849, in install_eggs
File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 1130, in build_and_install
File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 1115, in run_setup
File "build/bdist.linux-x86_64/egg/setuptools/sandbox.py", line 69, in run_setup
File "build/bdist.linux-x86_64/egg/setuptools/sandbox.py", line 120, in run
File "build/bdist.linux-x86_64/egg/setuptools/sandbox.py", line 71, in <lambda>
File "setup.py", line 23, in <module>
File "/usr/lib/python2.7/distutils/core.py", line 112, in setup
_setup_distribution = dist = klass(attrs)
File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 265, in __init__
File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 289, in fetch_build_eggs
File "build/bdist.linux-x86_64/egg/pkg_resources.py", line 618, in resolve
File "build/bdist.linux-x86_64/egg/pkg_resources.py", line 862, in best_match
File "build/bdist.linux-x86_64/egg/pkg_resources.py", line 874, in obtain
File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 339, in fetch_build_egg
File "build/bdist.linux-x86_64/egg/setuptools/command/easy_install.py", line 611, in easy_install
File "build/bdist.linux-x86_64/egg/setuptools/package_index.py", line 541, in fetch_distribution
File "build/bdist.linux-x86_64/egg/setuptools/package_index.py", line 455, in download
File "build/bdist.linux-x86_64/egg/setuptools/package_index.py", line 711, in _download_url
File "build/bdist.linux-x86_64/egg/setuptools/package_index.py", line 718, in _attempt_download
File "build/bdist.linux-x86_64/egg/setuptools/package_index.py", line 608, in _download_to
AttributeError: 'NoneType' object has no attribute 'group'
Originally reported by: tiran (Bitbucket: tiran, GitHub: tiran)
For setuptools 0.6 ez_setup.py used to validate the downloaded file against a table of known hashsums. I wonder ... why was this feature removed? It adds a simple layer of security and prevents broken downloads, too.
Python 2.4+ support SHA-1, 2.5+ SHA-2 family (sha224 to sha512). Since setuptools still supports Python 2.4 we have to use SHA-1. It's broken but not as broken as MD5. You can limit the possibility of a collision attack if you include and verify the file size, too.
Originally reported by: philip_thiem (Bitbucket: philip_thiem, GitHub: Unknown)
On win32 x python3.1 running "setup.py clean" exits with:
#!python
Skipping implicit fixer: buffer
Skipping implicit fixer: idioms
Skipping implicit fixer: set_literal
Skipping implicit fixer: ws_comma
Can't parse build\src\build\src\build\src\setuptools\sandbox.py: ParseError: bad
input: type=1, value='exec', context=(' ', (68, 24))
Can't parse build\src\build\src\build\lib\setuptools\sandbox.py: ParseError: bad
input: type=1, value='exec', context=(' ', (68, 24))
running clean
Originally reported by: flimm (Bitbucket: flimm, GitHub: flimm)
Currently, the Pypi home page of Distribute indicates that Distribute is deprecated, replaced by Setuptools.
However, the Pypi home page of Setuptools is ancient, only displaying information for Setuptools 0.6c11, which isn't compatible with Python 3, among other shortcomings.
If Distribute is truly ready to be replaced by Setuptools, then the Pypi home page of Setuptools should be updated.
If not, the name Distribute should be kept and it should not be marked as deprecated.
If you look at this StackOverflow post, you can see that the packaging situation for Python is confusing enough as it is already. It is not helpful to have Distribute as the recommended option, only to have it marked as deprecated on its Pypi home page, without updating the Setuptools Pypi home page.
Documentation should not be updated before everything has been released. We made this mistake with Distutils2/packaging, you can find plenty of documentation and blog posts stating that it is in Python 3.3, when that is not the case.
Originally reported by: idella5 (Bitbucket: idella5, GitHub: idella5)
under py2.5 this
ERROR: Regression test for Distribute issue #318
----------------------------------------------------------------------
Traceback (most recent call last):
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-python2_5/setuptools/tests/test_easy_install.py", line 276, in test_setup_requires
lambda: run_setup(test_setup_py, ['install'])
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-python2_5/setuptools/tests/test_easy_install.py", line 423, in reset_setup_stop_context
f()
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-python2_5/setuptools/tests/test_easy_install.py", line 276, in <lambda>
lambda: run_setup(test_setup_py, ['install'])
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-python2_5/setuptools/sandbox.py", line 67, in run_setup
lambda: execfile(
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-python2_5/setuptools/sandbox.py", line 117, in run
return func()
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-python2_5/setuptools/sandbox.py", line 69, in <lambda>
{'__file__':setup_script, '__name__':'__main__'}
File "setup.py", line 2, in <module>
File "/usr/lib64/python2.5/distutils/core.py", line 168, in setup
raise SystemExit, "error: " + str(msg)
SystemExit: error: can't create or remove files in install directory
The following error occurred while trying to add or remove files in the
installation directory:
[Errno 13] Permission denied: '/usr/lib64/python2.5/site-packages/test-easy-install-20044.write-test'
Well, oh dear, we can't write to system installed python in the middle of a test run.
Maybe this is distro specific, maybe it's not. Offhand I don't know where to pass or parse the option for --prefix= or --install-dir= in a run if python setup.py test. With that we can then tell it use some source dir for the duration of the test run of even make a writable dir for it. Why this only trips over in py2.5 I don't know.
The remainder are failures run under pypy.
pypy1.9 has FAILED (failures=1, errors=4)
ERROR: test_develop (setuptools.tests.test_develop.TestDevelopTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/tests/test_develop.py", line 76, in test_develop
cmd.ensure_finalized()
File "/usr/lib64/pypy1.9/lib-python/2.7/distutils/cmd.py", line 109, in ensure_finalized
self.finalize_options()
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/command/develop.py", line 51, in finalize_options
easy_install.finalize_options(self)
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/command/easy_install.py", line 232, in finalize_options
self.create_home_path()
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/command/easy_install.py", line 1317, in create_home_path
if path.startswith(home) and not os.path.isdir(path):
AttributeError: 'NoneType' object has no attribute 'startswith'
======================================================================
ERROR: test_local_index (setuptools.tests.test_easy_install.TestUserInstallTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/tests/test_easy_install.py", line 214, in test_local_index
cmd.ensure_finalized()
File "/usr/lib64/pypy1.9/lib-python/2.7/distutils/cmd.py", line 109, in ensure_finalized
self.finalize_options()
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/command/easy_install.py", line 232, in finalize_options
self.create_home_path()
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/command/easy_install.py", line 1317, in create_home_path
if path.startswith(home) and not os.path.isdir(path):
AttributeError: 'NoneType' object has no attribute 'startswith'
======================================================================
ERROR: test_setup_requires (setuptools.tests.test_easy_install.TestUserInstallTest)
Regression test for Distribute issue #318
----------------------------------------------------------------------
Traceback (most recent call last):
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/tests/test_easy_install.py", line 276, in test_setup_requires
lambda: run_setup(test_setup_py, ['install'])
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/tests/test_easy_install.py", line 423, in reset_setup_stop_context
f()
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/tests/test_easy_install.py", line 276, in <lambda>
lambda: run_setup(test_setup_py, ['install'])
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/sandbox.py", line 67, in run_setup
lambda: execfile(
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/sandbox.py", line 117, in run
return func()
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/sandbox.py", line 69, in <lambda>
{'__file__':setup_script, '__name__':'__main__'}
File "setup.py", line 2, in <module>
File "/usr/lib64/pypy1.9/lib-python/2.7/distutils/core.py", line 152, in setup
dist.run_commands()
File "/usr/lib64/pypy1.9/lib-python/2.7/distutils/dist.py", line 953, in run_commands
self.run_command(cmd)
File "/usr/lib64/pypy1.9/lib-python/2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/command/install.py", line 73, in run
self.do_egg_install()
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/command/install.py", line 87, in do_egg_install
cmd.ensure_finalized() # finalize before bdist_egg munges install cmd
File "/usr/lib64/pypy1.9/lib-python/2.7/distutils/cmd.py", line 109, in ensure_finalized
self.finalize_options()
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/command/easy_install.py", line 232, in finalize_options
self.create_home_path()
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/command/easy_install.py", line 1317, in create_home_path
if path.startswith(home) and not os.path.isdir(path):
AttributeError: 'NoneType' object has no attribute 'startswith'
======================================================================
ERROR: test_user_install_implied (setuptools.tests.test_easy_install.TestUserInstallTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/tests/test_easy_install.py", line 172, in test_user_install_implied
cmd.ensure_finalized()
File "/usr/lib64/pypy1.9/lib-python/2.7/distutils/cmd.py", line 109, in ensure_finalized
self.finalize_options()
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/command/easy_install.py", line 232, in finalize_options
self.create_home_path()
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/command/easy_install.py", line 1317, in create_home_path
if path.startswith(home) and not os.path.isdir(path):
AttributeError: 'NoneType' object has no attribute 'startswith'
======================================================================
FAIL: /mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/tests/api_tests.txt
Doctest: api_tests.txt
----------------------------------------------------------------------
Traceback (most recent call last):
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/setuptools/tests/doctest.py", line 2167, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for api_tests.txt
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/tests/api_tests.txt", line 0
----------------------------------------------------------------------
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/tests/api_tests.txt", line 344, in api_tests.txt
Failed example:
print(im("sys_platform==")) # doctest: +ELLIPSIS
Expected:
unexpected EOF while parsing (...line 1)
Got:
invalid syntax (<string>, line 1)
----------------------------------------------------------------------
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy1_9/tests/api_tests.txt", line 356, in api_tests.txt
Failed example:
print(im("(extra")) # doctest: +ELLIPSIS
Expected:
unexpected EOF while parsing (...line 1)
Got:
parenthesis is never closed (<string>, lines 1-2)
Well pypy1.9 is a superseded version so how much interest this draws I dare not anticipate.
pypy2.0
FAILED (failures=1)
File "/mnt/gen2/TmpDir/portage/dev-python/setuptools-0.7.2/work/setuptools-0.7.2-pypy2_0/tests/api_tests.txt", line 356, in api_tests.txt
Failed example:
print(im("(extra")) # doctest: +ELLIPSIS
Expected:
unexpected EOF while parsing (...line 1)
Got:
parenthesis is never closed (<string>, lines 1-2)
This rather surprises, pypy still riding on the back of py2.7
Originally reported by: jaraco (Bitbucket: jaraco, GitHub: jaraco)
Setuptools has been around for quite a while (almost 10 years), and the code base shows some of that age. Since then, the community has established preferred code style guidelines (a la PEP-8) and developed better practices. Additionally, none of the versions of Python supported by Setuptools today were around when Setuptools was started.
I'd like to see the Setuptools codebase updated to conform more closely to the expectations of a modern project.
In particular, let's:
This effort is the type of effort that most anyone could do, but I'd like to reserve this effort for a specific individual (or group sprint) who would like to become more familiar with the code base with a relatively innocuous effort.
In order to avoid duplication of effort, if you would like to volunteer for this effort, please assign this ticket to yourself, fork the project, and put together a pull request. Try to make frequent, bite-sized commits with descriptive commit messages for easy review.
Thanks!
Originally reported by: Anonymous
The following issue caused a lot of pain last year:
https://bitbucket.org/tarek/distribute/issue/334/
As of setuptools 0.8b6 it hasn't been merged back into setuptools,
and stuff has begun to break again. Upcoming pip 1.4 requires
0.8 for wheel support, this might end up trapping some users
in a no-win situation (distribute breaks this, setuptools breaks that).
Originally reported by: jaraco (Bitbucket: jaraco, GitHub: jaraco)
Setuptools currently defines dependency links to resolve its dependencies. From setup.py:
dependency_links = [
'https://pypi.python.org/packages/source/c/certifi/certifi-0.0.8.tar.gz#md5=dc5f5e7f0b5fc08d27654b17daa6ecec',
'https://pypi.python.org/packages/source/s/ssl/ssl-1.16.tar.gz#md5=fb12d335d56f3c8c7c1fefc1c06c4bfb',
'https://pypi.python.org/packages/source/w/wincertstore/wincertstore-0.1.zip#md5=2f9accbebe8f7b4c06ac7aa83879b81c',
'https://bitbucket.org/pypa/setuptools/downloads/ctypes-1.0.2.win32-py2.4.exe#md5=9092a0ad5a3d79fa2d980f1ddc5e9dbc',
'https://bitbucket.org/pypa/setuptools/downloads/ssl-1.16-py2.4-win32.egg#md5=3cfa2c526dc66e318e8520b6f1aadce5',
'https://bitbucket.org/pypa/setuptools/downloads/ssl-1.16-py2.5-win32.egg#md5=85ad1cda806d639743121c0bbcb5f39b',
],
Those links are there to support fetching of packages over SSL with certificate validation. The binary builds of ctypes and ssl are there for Windows users on Python 2.4 and 2.5 because those builds aren't available on PyPI. Ideally, these should be hosted on PyPI.
I'm less sure why there are links to the source files. Presumably setuptools could discover those download links. I suspect the reason they're there is that before setuptools has SSL support, there's no secure way to bootstrap SSL support, so those links provide at least some assurance that the package downloaded is the package setuptools expects.
Once SSL is bootstrapped, however, the clients can then rely on the public key infrastructure to authenticate the server and secure the connection.
Is there a way to accomplish this without the dependency links?
Originally reported by: tiran (Bitbucket: tiran, GitHub: tiran)
ez_setup._extractall() should validate the tar file members according to http://docs.python.org/3/library/tarfile.html#tarfile.TarFile.extractall
I suggest that _extractall() shall raise an error if
I also propose to mask out problematic bits like SUID. After all ez_setup.py is usually run with root permission.
#!python
for tarinfo in members:
if tarinfo.name.startswith('/') or '../' in tarinfo.name:
raise ValueError("Absolute file names or directory traversal forbidden: %s"
% tarinfo.name)
if tarinfo.isdir():
# Extract directories with a safe mode.
directories.append(tarinfo)
tarinfo = copy.copy(tarinfo)
tarinfo.mode = 448 # decimal for oct 0700
elif tarinfo.isreg():
tarinfo.mode &= 511 # 0777, mask out SUID, SGID, VTX
else:
raise ValueError("unsupported file type for file %s" % tarinfo.name)
Originally reported by: madhusudancs (Bitbucket: madhusudancs, GitHub: madhusudancs)
What does this https://bitbucket.org/pypa/setuptools/src/7d2d455b0cd32e95262e5baffcb96bd822340473/pkg_resources.py?at=default#cl-2489 and
mean? If the code enters require() method, it is always supposed to raise an exception?
Originally reported by: adrian (Bitbucket: adrian, GitHub: adrian)
When building a namespace package, Setuptools checks (by searching in the code) whether the __init__.py
therein calls declare_namespace
from pkg_resources
. If it doesn't it, it logs a warning, emitted here, which reads:
WARNING: (package) is a namespace package, but its init.py does not declare_namespace(); setuptools 0.7 will REQUIRE this! (See the setuptools manual under "Namespace Packages" for details.)
First of all, setuptools 0.7 now exists, so the future tense is somewhat worrisome. Also, I'm not sure whether requiring a declare_namespace
call is actually in the plans anymore. (My package, for example, accomplishes namespace packages using pkgutil.extend_path
from the standard library instead.) Some clarification, either in the warning or the docs, about what the plans are here would be helpful.
Originally reported by: agroszer (Bitbucket: agroszer, GitHub: agroszer)
http://winbot.zope.org/builders/setuptools_master%20py_244_win32/builds/2/steps/test/logs/stdio
Traceback (most recent call last):
File "c:\buildslave\setuptools_master_py_244_win32\build\setuptools\tests\test_packageindex.py", line 150, in test_md5
self.assertEqual(checker.hash.name, 'md5')
AttributeError: name
Originally reported by: y-p (Bitbucket: y-p, GitHub: y-p)
λ wget https://bitbucket.org/pypa/setuptools/raw/0.8/ez_setup.py -O - | python
Resolving bitbucket.org (bitbucket.org)... 207.223.240.182, 207.223.240.181
Connecting to bitbucket.org (bitbucket.org)|207.223.240.182|:443... connected.
HTTP request sent, awaiting response... 404 NOT FOUND
2013-06-28 22:28:47 ERROR 404: NOT FOUND.
Originally reported by: jurko (Bitbucket: jurko, GitHub: jurko)
setuptools/tests/test_easy_install.py module should not use the try/except/finally construct and should instead use a try/except block wrapped inside a separate try/finally block.
Without this we get ugly warnings/errors when installing setuptools on Python 3.2. This has been noticed when using the ez_setup.py bootstrap script called from another installation package, with setuptools version 0.7.2.
Current code:
try:
reset_setup_stop_context(
lambda: run_setup(test_setup_py, ['install'])
)
except SandboxViolation:
self.fail('Installation caused SandboxViolation')
finally:
sys.stdout = old_stdout
sys.stderr = old_stderr
Corrected code (untested):
try:
try:
reset_setup_stop_context(
lambda: run_setup(test_setup_py, ['install'])
)
except SandboxViolation:
self.fail('Installation caused SandboxViolation')
finally:
sys.stdout = old_stdout
sys.stderr = old_stderr
Originally reported by: Anonymous
Running ez_setup.py is the recommended way to install setuptools on Windows, but it installs version 0.8 instead of the latest (currently 0.9.6).
Originally reported by: tiran (Bitbucket: tiran, GitHub: tiran)
ez_setup.DEFAULT_URL points to "http://pypi.python.org/packages/source/s/setuptools/". It should use https instead. At least some versions of Python validate the server cert on some platforms.
Originally reported by: jaraco (Bitbucket: jaraco, GitHub: jaraco)
In #28 and Distribute #375, a regression was reported where an attribute was mis-named. Since this behavior wasn't covered by unit tests, the error was not discovered until the users experienced it.
Let's add one or more unit tests for ResourceManager.get_cache_path to ensure this doesn't occur again.
Originally reported by: yyuu (Bitbucket: yyuu, GitHub: yyuu)
The installation script failed on the latest Jython beta release of 2.7-beta1.
I tested with beta release of 2.7 because current release version (2.5.3) lacks ssl
module.
% python --version
Jython 2.7b1
% python setup.py install
Traceback (most recent call last):
File "setup.py", line 145, in <module>
for cmd in SETUP_COMMANDS
File "/home/yyuu/.pyenv/versions/jython-2.7-beta1/Lib/distutils/core.py", line 112, in setup
_setup_distribution = dist = klass(attrs)
File "/home/yyuu/.pyenv/versions/jython-2.7-beta1/Lib/distutils/core.py", line 112, in setup
_setup_distribution = dist = klass(attrs)
File "/home/yyuu/work/repos/hg/setuptools/setuptools/dist.py", line 266, in __init__
_Distribution.__init__(self,attrs)
File "/home/yyuu/.pyenv/versions/jython-2.7-beta1/Lib/distutils/dist.py", line 287, in __init__
self.finalize_options()
File "/home/yyuu/work/repos/hg/setuptools/setuptools/dist.py", line 298, in finalize_options
ep.require(installer=self.fetch_build_egg)
File "/home/yyuu/work/repos/hg/setuptools/pkg_resources.py", line 2185, in require
map(working_set.add,
File "/home/yyuu/work/repos/hg/setuptools/pkg_resources.py", line 2403, in requires
dm = self._dep_map
File "/home/yyuu/work/repos/hg/setuptools/pkg_resources.py", line 2392, in _dep_map
if invalid_marker(marker):
File "/home/yyuu/work/repos/hg/setuptools/pkg_resources.py", line 1209, in invalid_marker
evaluate_marker(text)
File "/home/yyuu/work/repos/hg/setuptools/pkg_resources.py", line 1209, in invalid_marker
evaluate_marker(text)
File "/home/yyuu/work/repos/hg/setuptools/pkg_resources.py", line 1292, in evaluate_marker
import parser
ImportError: No module named parser
// BTW, new setuptools should support Jython?
Originally reported by: jaraco (Bitbucket: jaraco, GitHub: jaraco)
In setuptools 0.9.1, the code was changed to reduce the number of places where the version number was recorded. To accomplish this, it imported setuptools and read setuptools.__version__
. It turns out that in the upgrade scenario, this causes the new version of setuptools to be installed but with the older version number. Observe:
jenkins@myhost:~/jobs/myapp/workspace/services$ virtualenv --setuptools myservice
New python executable in myservice/bin/python2.7
Also creating executable in myservice/bin/python
Installing setuptools............done.
Installing pip...............done.
jenkins@myhost:~/jobs/myapp/workspace/services$ myservice/bin/easy_install setuptools==0.9.3
Searching for setuptools==0.9.3
Reading http://pypi.python.org/simple/setuptools/
Reading http://peak.telecommunity.com/snapshots/
Reading https://pypi.python.org/pypi/setuptools
Best match: setuptools 0.9.3
Downloading https://pypi.python.org/packages/source/s/setuptools/setuptools-0.9.3.tar.gz#md5=142b8891558ae09fa3b3070e88dca004
Processing setuptools-0.9.3.tar.gz
Running setuptools-0.9.3/setup.py -q bdist_egg --dist-dir /tmp/easy_install-SbxnMA/setuptools-0.9.3/egg-dist-tmp-QR2x8j
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'src_root'
warnings.warn(msg)
setuptools 0.6c11 is already the active version in easy-install.pth
Installing easy_install script to /var/lib/jenkins/jobs/myapp/workspace/services/myservice/bin
Installing easy_install-2.7 script to /var/lib/jenkins/jobs/myapp/workspace/services/myservice/bin
Installed /var/lib/jenkins/jobs/myapp/workspace/services/myservice/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg
Processing dependencies for setuptools==0.6c11
Finished processing dependencies for setuptools==0.6c11
Originally reported by: philip_thiem (Bitbucket: philip_thiem, GitHub: Unknown)
On win32 x Python 3.0, "setup.py install" fails with;
#!python
Skipping implicit fixer: buffer
Skipping implicit fixer: idioms
Skipping implicit fixer: set_literal
Skipping implicit fixer: ws_comma
Traceback (most recent call last):
File "setup.py", line 220, in <module>
scripts = [],
File "c:\python30\lib\distutils\core.py", line 135, in setup
ok = dist.parse_command_line()
File "C:\development\setuptools\build\src\setuptools\dist.py", line 273, in pa
rse_command_line
result = _Distribution.parse_command_line(self)
File "c:\python30\lib\distutils\dist.py", line 441, in parse_command_line
if self.handle_display_options(option_order):
File "C:\development\setuptools\build\src\setuptools\dist.py", line 713, in ha
ndle_display_options
sys.stdout.detach(), 'utf-8', errors, newline, line_buffering)
AttributeError: 'TextIOWrapper' object has no attribute 'detach'
Originally reported by: jurko (Bitbucket: jurko, GitHub: jurko)
Installed Python 2.4 on Windows.
Installed setuptools 0.7.2 into the new Python 2.4 installation.
And then running easy_install on any package fails to download the package from PyPI.
If you change the package's PyPI URL using the easy_install's -i option to use HTTP instead of HTTPS - then everything works fine.
Sniffing the network traffic with Wireshark shows that the client simply shuts down the network connection after receiving a 'hello' message from the server.
Reproduced using:
Python 2.4.3/x86 on Windows 7/SP1/x64 with setuptools 0.7.2
The problem DOES NOT occur when using Python 2.4.4:
Python 2.4.4/x86 on Windows 7/SP1/x64 with setuptools 0.7.2
Console session demonstrating the problem:
C:\>py24 -m easy_install pytest
Searching for pytest
Reading https://pypi.python.org/simple/pytest/
Download error on https://pypi.python.org/simple/pytest/: (2, 'The operation did not complete (read)') -- Some packages may not be found!
Couldn't find index page for 'pytest' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading https://pypi.python.org/simple/
Download error on https://pypi.python.org/simple/: (2, 'The operation did not complete (read)') -- Some packages may not be found!
No local packages or download links found for pytest
error: Could not find suitable distribution for Requirement.parse('pytest')
C:\>py24 -m easy_install -i https://pypi.python.org/simple pytest
Searching for pytest
Reading https://pypi.python.org/simple/pytest/
Download error on https://pypi.python.org/simple/pytest/: (2, 'The operation did not complete (read)') -- Some packages may not be found!
Couldn't find index page for 'pytest' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading https://pypi.python.org/simple/
Download error on https://pypi.python.org/simple/: (2, 'The operation did not complete (read)') -- Some packages may not be found!
No local packages or download links found for pytest
error: Could not find suitable distribution for Requirement.parse('pytest')
C:\>py24 -m easy_install -i http://pypi.python.org/simple pytest
Searching for pytest
Reading http://pypi.python.org/simple/pytest/
Best match: pytest 2.3.5
Downloading http://pypi.python.org/packages/source/p/pytest/pytest-2.3.5.tar.gz#md5=18f150e7be96b5fe3c388b0e817b8087
Processing pytest-2.3.5.tar.gz
Writing c:\users\jurko\appdata\local\temp\easy_install-obyruy\pytest-2.3.5\setup.cfg
...installation continues from here on...
C:\>py24 -m easy_install -i https://pypi.python.org/simple psutil
Searching for psutil
Reading https://pypi.python.org/simple/psutil/
Download error on https://pypi.python.org/simple/psutil/: (2, 'The operation did not complete (read)') -- Some packages may not be found!
Couldn't find index page for 'psutil' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading https://pypi.python.org/simple/
Download error on https://pypi.python.org/simple/: (2, 'The operation did not complete (read)') -- Some packages may not be found!
No local packages or download links found for psutil
error: Could not find suitable distribution for Requirement.parse('psutil')
C:\>py24 -m easy_install -i http://pypi.python.org/simple psutil
Searching for psutil
Reading http://pypi.python.org/simple/psutil/
Reading http://code.google.com/p/psutil/
Best match: psutil 0.7.1
Downloading http://psutil.googlecode.com/files/psutil-0.7.1.tar.gz
Processing psutil-0.7.1.tar.gz
Writing c:\users\jurko\appdata\local\temp\easy_install-q6zmk_\psutil-0.7.1\setup.cfg
...installation continues from here on...
The problem seems to be caused somewhere in Python's HTTPS implementation. Should setuptools then revert to using HTTP on such platforms?
This causes different setup packages on such platforms to fail when they attempt to download their requirement packages. The only workaround I could find for this behaviour as a setup packager was to do something like this in my package.py script:
if sys.version_info < (2, 5):
# Python 2.4 seems to have issues with setuptools collecting its
# requirement packages from PyPI using HTTPS. This has been encountered
# using Python 2.4.3/x86 on Windows 7/SP1/x64 with setuptools 0.7.2. As a
# workaround we replace setuptools's PackageIndex class with one that
# always uses the HTTP transfer protocol instead of HTTPS when dealing with
# this Python version.
#
# Note that this workaround affects only setuptools's automated requirement
# package downloading. Any requirement packages can still be installed
# manually by the user, using a suitable package index source URL.
import setuptools.package_index
OriginalPackageIndex = setuptools.package_index.PackageIndex
class NoHTTPSPackageIndex(OriginalPackageIndex):
def __init__(self, *args, **kwargs):
OriginalPackageIndex.__init__(self, *args, **kwargs)
cue = "https:"
if self.index_url.lower().startswith(cue):
self.index_url = "http:" + self.index_url[len(cue):]
setuptools.package_index.PackageIndex = NoHTTPSPackageIndex
but the solution seems rather hackish and I am not really sure how portable/stable it will be over different setuptools releases.
Best regards,
Jurko Gospodnetić
Originally reported by: Anonymous
since 0.7.x, there are some issues in the tarball setuptools.egg-info directory...namely:
This should be trivial to fix in the source tree. extract below from the 0.8 tarball:
drwxrwxrwx 0/0 0 2013-07-05 19:12 setuptools-0.8/setuptools.egg-info/
-rw-rw-rw- 0/0 654 2013-07-05 19:12 setuptools-0.8/setuptools.egg-info/dependency_links.txt
drwxrwxrwx 0/0 0 2013-07-05 19:12 setuptools-0.8/setuptools.egg-info/EGG-INFO/
-rw-rw-rw- 0/0 153 2013-07-02 17:30 setuptools-0.8/setuptools.egg-info/EGG-INFO/PKG-INFO
-rw-rw-rw- 0/0 2773 2013-07-05 19:12 setuptools-0.8/setuptools.egg-info/entry_points.txt
-rw-rw-rw- 0/0 2773 2013-07-03 14:12 setuptools-0.8/setuptools.egg-info/entry_points.txt.orig
-rw-rw-rw- 0/0 45823 2013-07-05 19:12 setuptools-0.8/setuptools.egg-info/PKG-INFO
-rw-rw-rw- 0/0 186 2013-07-05 19:12 setuptools-0.8/setuptools.egg-info/requires.txt
-rw-rw-rw- 0/0 186 2013-07-03 14:12 setuptools-0.8/setuptools.egg-info/requires.txt.orig
-rw-rw-rw- 0/0 3663 2013-07-05 19:12 setuptools-0.8/setuptools.egg-info/SOURCES.txt
-rw-rw-rw- 0/0 49 2013-07-05 19:12 setuptools-0.8/setuptools.egg-info/top_level.txt
-rw-rw-rw- 0/0 2 2013-07-02 17:48 setuptools-0.8/setuptools.egg-info/zip-safe
Originally reported by: jaraco (Bitbucket: jaraco, GitHub: jaraco)
There would be many advantages to dropping support for Python 2.4, particularly, it would enable the following important features:
Furthermore, much of the backward-compatibility code could be eliminated. Once #35 is completed, I'd like to explore dropping support for Python 2.4. Are there any steps that can be taken in advance to prepare for this transition? In particular, I'd like the remaining clients of Python 2.4 to continue to have a version of setuptools that's stable (e.g. Setuptools 0.9).
Originally reported by: jaraco (Bitbucket: jaraco, GitHub: jaraco)
In this Travis-CI run, we see setuptools fails two publish API tests in the environment marker support:
File "/home/travis/build/jaraco/setuptools/tests/api_tests.txt", line 344, in api_tests.txt
Failed example:
print(im("sys_platform==")) # doctest: +ELLIPSIS
Expected:
unexpected EOF while parsing (...line 1)
Got:
invalid syntax (<string>, line 1)
and
File "/home/travis/build/jaraco/setuptools/tests/api_tests.txt", line 356, in api_tests.txt
Failed example:
print(im("(extra")) # doctest: +ELLIPSIS
Expected:
unexpected EOF while parsing (...line 1)
Got:
parenthesis is never closed (<string>, lines 1-2)
It seems the differences in the parser yield different error messages.
Either the API expectations need to be relaxed or setuptools needs to wrap this call to translate the error messages when invoked on PyPy.
Originally reported by: mgedmin (Bitbucket: mgedmin, GitHub: mgedmin)
Steps to reproduce:
$ virtualenv tmpenv
...
New python executable in tmpenv/bin/python
Installing setuptools............done.
Installing pip...............done.
$ wget http://downloads.buildout.org/2/bootstrap.py
...
$ tmpenv/bin/python bootstrap.py
Traceback (most recent call last):
File "bootstrap.py", line 78, in <module>
ez['use_setuptools'](**setup_args)
File "<string>", line 151, in use_setuptools
File "/tmp/tmpenv/local/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/pkg_resources.py", line 666, in require
File "/tmp/tmpenv/local/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg/pkg_resources.py", line 569, in resolve
pkg_resources.VersionConflict: (setuptools 0.6c11 (/tmp/tmpenv/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg), Requirement.parse('setuptools>=0.7b'))
What bootstrap.py does is try to install distribute when it finds setuptools in the outer Python
exec(urlopen('http://python-distribute.org/distribute_setup.py').read(), ez)
setup_args = dict(to_dir=tmpeggs, download_delay=0, no_fake=True)
ez['use_setuptools'](**setup_args)
It looks like this might be the commit that introduced this problem (thanks to Troy J. Farrell for finding it).
As a workaround I can use virtualenv --distribute
in step 1. But not every instance of this problem involves a virtualenv -- the Zope Windows buildbot is all red today, with similar errors, and there's no virtualenv in the picture.
Originally reported by: giszmo (Bitbucket: giszmo, GitHub: giszmo)
having 'http://user:[email protected]#egg=cns-lib' in my dependency_links results in:
#!shell
...
Best match: cns-lib [unknown version]
Downloading http://user:[email protected]#egg=cns-lib
Traceback (most recent call last):
File "setup.py", line 35, in <module>
setup(**constants)
File "/usr/lib/python3.2/distutils/core.py", line 148, in setup
dist.run_commands()
File "/usr/lib/python3.2/distutils/dist.py", line 917, in run_commands
self.run_command(cmd)
File "/usr/lib/python3.2/distutils/dist.py", line 936, in run_command
cmd_obj.run()
File "/home/leo/git/virtpy/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/command/develop.py", line 27, in run
self.install_for_development()
File "/home/leo/git/virtpy/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/command/develop.py", line 105, in install_for_development
self.process_distribution(None, self.dist, not self.no_deps)
File "/home/leo/git/virtpy/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/command/easy_install.py", line 673, in process_distribution
[requirement], self.local_index, self.easy_install
File "/home/leo/git/virtpy/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/pkg_resources.py", line 576, in resolve
dist = best[req.key] = env.best_match(req, self, installer)
File "/home/leo/git/virtpy/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/pkg_resources.py", line 822, in best_match
return self.obtain(req, installer) # try and download/install
File "/home/leo/git/virtpy/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/pkg_resources.py", line 834, in obtain
return installer(requirement)
File "/home/leo/git/virtpy/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/command/easy_install.py", line 576, in easy_install
self.local_index
File "/home/leo/git/virtpy/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/package_index.py", line 488, in fetch_distribution
dist = find(requirement)
File "/home/leo/git/virtpy/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/package_index.py", line 475, in find
location=self.download(dist.location, tmpdir)
File "/home/leo/git/virtpy/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/package_index.py", line 414, in download
found = self._download_url(scheme.group(1), spec, tmpdir)
File "/home/leo/git/virtpy/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/package_index.py", line 663, in _download_url
return self._attempt_download(url, filename)
File "/home/leo/git/virtpy/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/package_index.py", line 672, in _attempt_download
headers = self._download_to(url, filename)
File "/home/leo/git/virtpy/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/package_index.py", line 571, in _download_to
fp = self.open_url(url)
File "/home/leo/git/virtpy/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/package_index.py", line 610, in open_url
return open_with_auth(url)
File "/home/leo/git/virtpy/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/package_index.py", line 753, in _socket_timeout
return func(*args, **kwargs)
File "/home/leo/git/virtpy/lib/python3.2/site-packages/distribute-0.6.24-py3.2.egg/setuptools/package_index.py", line 771, in open_with_auth
auth = "Basic " + urllib.parse.unquote(auth).encode('base64').strip()
LookupError: unknown encoding: base64
I can "pip install git+ssh://[email protected]/cns-lib.git" but wasn't able to translate that for setuptools neither. Maybe there is some misunderstanding on my side. Being able to bootstrap our project with the private dependencies loaded via setuptools would really be cool
Originally reported by: tiran (Bitbucket: tiran, GitHub: tiran)
ez_setup.download_setuptools() doesn't limit the amount of data that is downloaded with urllib. An attacker can forge a HTTP response with a large or even infinite file (e.g. netcat < /dev/zero). This can consume lots of memory or occupy lots of disk space on /tmp. src.read() should be limited to a sane value (e.g. 2-5 MB) and raise an error if more data is downloaded.
ez_setup._extractall() should be limited, too. It's open to zip decompression bomb vulnerability.
Originally reported by: jaraco (Bitbucket: jaraco, GitHub: jaraco)
Currently, the README indicates that to upgrade from distribute, one must uninstall distribute first. In fact, it may not even say that explicitly enough.
Upgrades from setuptools work nicely. I'd like to explore an approach that will make a nicer transition from distribute as well.
Here's what I have in mind:
Create a new release of distribute 0.7. Installation of distribute 0.7 will:
This ticket is to explore the viability of such an approach.
Originally reported by: jaraco (Bitbucket: jaraco, GitHub: jaraco)
The default test runner, as invoked by 'setup.py test', fails to execute tests in tests/*.py (test_pkg_resources and test_ez_setup). I believe this is because the "test_suite" is defined as "setuptools.tests".
The tests can be run manually using another test runner, but it'd be preferable if the tests could be run using 'setup.py tests'. I'm open to suggestions on how to make this happen.
Originally reported by: the_drow (Bitbucket: the_drow, GitHub: Unknown)
#!python
pip install https://bitbucket.org/pypa/setuptools/downloads/distribute-0.7.3.zip --upgrade
Downloading/unpacking https://bitbucket.org/pypa/setuptools/downloads/distribute-0.7.3.zip
Downloading distribute-0.7.3.zip (145kB): 145kB downloaded
Running setup.py egg_info for package from https://bitbucket.org/pypa/setuptools/downloads/distribute-0.7.3.zip
Downloading/unpacking setuptools>=0.7 (from distribute==0.7.3)
Downloading setuptools-0.7.4.tar.gz (755kB): 755kB downloaded
Running setup.py egg_info for package setuptools
Traceback (most recent call last):
File "<string>", line 3, in <module>
File "setuptools/__init__.py", line 2, in <module>
from setuptools.extension import Extension, Library
File "setuptools/extension.py", line 5, in <module>
from setuptools.dist import _get_unpatched
File "setuptools/dist.py", line 103
except ValueError, e:
^
SyntaxError: invalid syntax
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
File "<string>", line 3, in <module>
File "setuptools/__init__.py", line 2, in <module>
from setuptools.extension import Extension, Library
File "setuptools/extension.py", line 5, in <module>
from setuptools.dist import _get_unpatched
File "setuptools/dist.py", line 103
except ValueError, e:
^
SyntaxError: invalid syntax
----------------------------------------
Cleaning up...
Command python setup.py egg_info failed with error code 1 in /home/omer/.virtualenvs/outcomes/build/setuptools
Storing complete log in /home/omer/.pip/pip.log
Originally reported by: hirokiky (Bitbucket: hirokiky, GitHub: hirokiky)
Hi.
Certairly this link will raise 404.
https://pypi.python.org/packages/source/s/setuptools/setuptools-0.9.6.tar.gz
I think it is not a problem caused by the source code.
This issue should not be written in the bitbucket.
But, I don't know where I should post it.
Originally reported by: agroszer (Bitbucket: agroszer, GitHub: agroszer)
http://winbot.zope.org/builders has now builders.
Note: some seem to pass, but fail on some atexit problem.
See http://winbot.zope.org/builders/setuptools_master%20py_265_win32/builds/0/steps/test/logs/stdio
Originally reported by: ncoghlan (Bitbucket: ncoghlan, GitHub: ncoghlan)
The error message received when a system installed package is missing a "namespace package" declaration is really cryptic. I encountered this for http://beaker-project.org when our common library was missing the namespace package declaration (it originally didn't seem necessary, since that package is the one that owns that namespace, and does have its __init__.py
file installed as part of the OS package)
When running from a source checkout, we don't actually care that the system version is present, because sys.path ensures the installed released version is ignored. This also holds true for bkr.__path__
.
However, because of the missing declaration, pkg_resources interprets this as an attempt to import a conflicting version of a top level module and ends up emitting a totally inappropriate error message from check_version_conflict() (see the final warning in
https://bitbucket.org/pypa/setuptools/src/6aa3034bc297e98ed1a8422d96754cc0d6734667/pkg_resources.py?at=default#cl-2545)
There should be something in declare_namespace() that checks for this and emits a less cryptic error message that makes it clear:
See http://stackoverflow.com/questions/13915269/why-do-i-get-userwarning-module-dap-was-already-imported-from-none/ for some background
Originally reported by: Ivoz (Bitbucket: Ivoz, GitHub: Ivoz)
Hi, as far as I know this is a desirable to provide a secure way to bootstrap into a "modern" python package installation environment.
@ncoghlan has advised me that currently it is planned to be hosted on pypi.python.org, available under their https connection.
Obvious use-case for this link would be to be allowed in documentation and setup scripts that wouldn't need to change with changes in Setuptools'/pip's version.
@r1chardj0n3s is currently writing a new pip-bootstrap for 3.4 (hopefully backportable)
AFAIK this would install latest versions of setuptools and pip, as they are rather symbiotic.
I just wished to create an issue to track progress of this and so I can update docs when it appears.
As of writing it can be found @ https://bitbucket.org/pypa/setuptools/raw/0.8/ez_setup.py
Analogously, scripts for distribute are hosted under http://python-distribute.org/ although that is not under HTTPS currently. pip's can be found currently at https://raw.github.com/pypa/pip/master/contrib/get-pip.py
Originally reported by: jaraco (Bitbucket: jaraco, GitHub: jaraco)
The use of StringIO in pkg_resources.resource_stream appears to be causing errors in setuptools 0.8:
> python
Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkg_resources
>>> pkg_resources.require('pytz')[0].version
'2013b'
>>> import pytz
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<frozen importlib._bootstrap>", line 1567, in _find_and_load
File "<frozen importlib._bootstrap>", line 1534, in _find_and_load_unlocked
File "c:\python\lib\site-packages\pytz-2013b-py3.3.egg\pytz\__init__.py", line 1103, in <module>
File "c:\python\lib\site-packages\pytz-2013b-py3.3.egg\pytz\__init__.py", line 1103, in <listcomp>
File "c:\python\lib\site-packages\pytz-2013b-py3.3.egg\pytz\__init__.py", line 107, in resource_exists
File "c:\python\lib\site-packages\pytz-2013b-py3.3.egg\pytz\__init__.py", line 100, in open_resource
File "c:\python\lib\site-packages\setuptools-0.8b5-py3.3.egg\pkg_resources.py", line 951, in resource_stream
File "c:\python\lib\site-packages\setuptools-0.8b5-py3.3.egg\pkg_resources.py", line 1405, in get_resource_stream
File "c:\python\lib\site-packages\setuptools-0.8b5-py3.3.egg\pkg_resources.py", line 1982, in StringIO
TypeError: initial_value must be str or None, not bytes
Originally reported by: khoppert (Bitbucket: khoppert, GitHub: Unknown)
Hi,
is there any interest in having an authentication while you are bootstrapping your project.
The authentication works for the find-links parameter in the buildout section and downstreamed for the eggs matched to index list in the restricted repository.
I developed a small piece of code which is doing such things.
The credentials are taken from a ~.pypirc file.
If an url is given to the open_with_auth method from package_index.py i am comparing the url to the repository urls which are in the repository sections of the pypirc file.
If credentials are found they are integrated in the open_with_auth authentication mechanism.
Greetings
Kai
Originally reported by: qwcode (Bitbucket: qwcode, GitHub: qwcode)
see pip travis build errors.
https://travis-ci.org/pypa/pip/jobs/9358736
#!python
"Validating %%s checksum for %s" % filename)
File "/home/travis/build/pypa/pip/tests/tests_cache/test_ws/.virtualenv/site-packages/setuptools/package_index.py", line 261, in report
msg = template % self._get_hash_name()
File "/home/travis/build/pypa/pip/tests/tests_cache/test_ws/.virtualenv/site-packages/setuptools/package_index.py", line 254, in _get_hash_name
return self.hash.name
AttributeError: 'HASH' object has no attribute 'name'
Originally reported by: qwcode (Bitbucket: qwcode, GitHub: qwcode)
egg_info.get_svn_revision in the new setuptools appears to be pretty different than the last version in distribute. Was that intentional?
pip happens to have a number of tests that use a svn checkout of INITools that are failing under the new setuptools in python3
here's the trace from one.
(in this case, data is a string, which is the contents of the svn entries file)
#!bash
Test checking out from svn. ... Script result: pip install -e svn+file:///home/qwcode/p/pypa/pip/tests/tests_cache/INITools/trunk#egg=initools-dev
return code: 1
-- stdout: --------------------
Obtaining initools from svn+file:///home/qwcode/p/pypa/pip/tests/tests_cache/INITools/trunk#egg=initools-dev
Checking out file:///home/qwcode/p/pypa/pip/tests/tests_cache/INITools/trunk to /home/qwcode/p/pypa/pip/tests/tests_cache/test_ws/.virtualenv/src/initools
Running setup.py egg_info for package initools
Traceback (most recent call last):
File "<string>", line 16, in <module>
File "/home/qwcode/p/pypa/pip/tests/tests_cache/test_ws/.virtualenv/src/initools/setup.py", line 26, in <module>
zip_safe=True,
File "/usr/local/lib/python3.3/distutils/core.py", line 148, in setup
dist.run_commands()
File "/usr/local/lib/python3.3/distutils/dist.py", line 917, in run_commands
self.run_command(cmd)
File "/usr/local/lib/python3.3/distutils/dist.py", line 935, in run_command
cmd_obj.ensure_finalized()
File "/usr/local/lib/python3.3/distutils/cmd.py", line 107, in ensure_finalized
self.finalize_options()
File "/home/qwcode/p/pypa/pip/tests/tests_cache/test_ws/.virtualenv/lib/python3.3/site-packages/setuptools/command/egg_info.py", line 85, in finalize_options
self.vtags = self.tags()
File "/home/qwcode/p/pypa/pip/tests/tests_cache/test_ws/.virtualenv/lib/python3.3/site-packages/setuptools/command/egg_info.py", line 192, in tags
): version += '-r%s' % self.get_svn_revision()
File "/home/qwcode/p/pypa/pip/tests/tests_cache/test_ws/.virtualenv/lib/python3.3/site-packages/setuptools/command/egg_info.py", line 233, in get_svn_revision
if data<8:
TypeError: unorderable types: str() < int()
Complete output from command python setup.py egg_info:
running egg_info
Traceback (most recent call last):
File "<string>", line 16, in <module>
File "/home/qwcode/p/pypa/pip/tests/tests_cache/test_ws/.virtualenv/src/initools/setup.py", line 26, in <module>
zip_safe=True,
File "/usr/local/lib/python3.3/distutils/core.py", line 148, in setup
dist.run_commands()
File "/usr/local/lib/python3.3/distutils/dist.py", line 917, in run_commands
self.run_command(cmd)
File "/usr/local/lib/python3.3/distutils/dist.py", line 935, in run_command
cmd_obj.ensure_finalized()
File "/usr/local/lib/python3.3/distutils/cmd.py", line 107, in ensure_finalized
self.finalize_options()
File "/home/qwcode/p/pypa/pip/tests/tests_cache/test_ws/.virtualenv/lib/python3.3/site-packages/setuptools/command/egg_info.py", line 85, in finalize_options
self.vtags = self.tags()
File "/home/qwcode/p/pypa/pip/tests/tests_cache/test_ws/.virtualenv/lib/python3.3/site-packages/setuptools/command/egg_info.py", line 192, in tags
): version += '-r%s' % self.get_svn_revision()
File "/home/qwcode/p/pypa/pip/tests/tests_cache/test_ws/.virtualenv/lib/python3.3/site-packages/setuptools/command/egg_info.py", line 233, in get_svn_revision
if data<8:
TypeError: unorderable types: str() < int()
Originally reported by: philip_thiem (Bitbucket: philip_thiem, GitHub: Unknown)
It is really interesting how far I've gotten sidetracked, but scratching the itch I suppose.
I was running the tests for pip on win32 and the SVN tests were failing, took a looked like there is an issue with metadata support for SVN 1.7.
I had tossed together a revision to get_svn_revision to get the pip's test suite to complete with 0.7.3dev and svn1.7. This revision is a bit different than my original patch but should get the idea across. I was surprised that the suite only choked on getting the revision. So, I have doubts about the completeness of the this fix.
Also I used the subprocess module (in a Python2.4+ compatible manner). However, I noticed a comment in the module saying that egg_info.py needed to be Python 2.3 compatible. Is this still true?
Looks like the change is pretty significant: Switching to a central sqllite database located in the root .svn directory. Some of the documentation would seem to indicate that they want people to use the command line tools to access this information and not the try to use it directly.
I had some concerns about testing. I have a test_svn.py which uses the command line to build the working directories for testing get_svn_revision(), but would seem wiser to just provide static copies of a checked out directory. SVN tests looks like they need to be expanded.
Here are some previous tickets on the issues as the issue tracker has migrated around:
This contains several patches for converting the current setup to a separate SVN class. This looks like a good idea (would probably be saner for testing)
Subversion 1.6 entries format 'unrecognized'
SVN Entries parsing should use local svn command for implementation
Subversion 1.7 introduces new storage format - breaks distribute svn support
Later i will grep the code for svn related routines and see if I missed anything.
Originally reported by: ncoghlan (Bitbucket: ncoghlan, GitHub: ncoghlan)
If a requirement in __main__.__requires__
is met by a package in site-packages, pkg_resources will happily reinsert site-packages at the front of sys.path.
This breaks the world when working on software where a previous version is installed as a system package.
Originally reported by: eseifert (Bitbucket: eseifert, GitHub: eseifert)
After I upgraded to setuptools 0.7.5 on my Gentoo system trac didn't start anymore. One of the plugin eggs failed with an AttributeError:
#!python
Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/trac/web/main.py", line 497, in _dispatch_request
dispatcher.dispatch(req)
File "/usr/lib64/python2.7/site-packages/trac/web/main.py", line 169, in dispatch
for handler in self.handlers:
File "/usr/lib64/python2.7/site-packages/trac/core.py", line 78, in extensions
components = [component.compmgr[cls] for cls in classes]
File "/usr/lib64/python2.7/site-packages/trac/core.py", line 199, in __getitem__
component = cls(self)
File "/usr/lib64/python2.7/site-packages/trac/core.py", line 138, in __call__
self.__init__()
File "build/bdist.linux-x86_64/egg/acct_mgr/web_ui.py", line 73, in __init__
self.acctmgr = AccountManager(self.env)
File "/usr/lib64/python2.7/site-packages/trac/core.py", line 138, in __call__
self.__init__()
File "build/bdist.linux-x86_64/egg/acct_mgr/api.py", line 235, in __init__
locale_dir = resource_filename(__name__, 'locale')
File "/usr/lib64/python2.7/site-packages/pkg_resources.py", line 945, in resource_filename
self, resource_name
File "/usr/lib64/python2.7/site-packages/pkg_resources.py", line 1633, in get_resource_filename
return self._extract_resource(manager, zip_path)
File "/usr/lib64/python2.7/site-packages/pkg_resources.py", line 1648, in _extract_resource
manager, os.path.join(zip_path, name)
File "/usr/lib64/python2.7/site-packages/pkg_resources.py", line 1648, in _extract_resource
manager, os.path.join(zip_path, name)
File "/usr/lib64/python2.7/site-packages/pkg_resources.py", line 1648, in _extract_resource
manager, os.path.join(zip_path, name)
File "/usr/lib64/python2.7/site-packages/pkg_resources.py", line 1660, in _extract_resource
self.egg_name, self._parts(zip_path)
File "/usr/lib64/python2.7/site-packages/pkg_resources.py", line 1021, in get_cache_path
self._warn_unsafe_extraction(extract_path)
AttributeError: ResourceManager instance has no attribute '_warn_unsafe_extraction'
I fixed the problem by changing the method name _warn_unsafe_extraction
to warn_unsafe_extraction_path
in pkg_resources.py as can be seen in the attached patch. I'm not sure if it's the correct way to fix this but it solved the issue for me.
Originally reported by: jaraco (Bitbucket: jaraco, GitHub: jaraco)
Julian and Andres have reported on distutils-sig an issue installing certain packages that incorporate distribute_setup and call use_setuptools.
For example, the following script will reproduce the issue when installing pudb:
#! /bin/sh
set -e
set -x
virtualenv --no-setuptools mypy
source mypy/bin/activate
curl -k https://bitbucket.org/pypa/setuptools/raw/0.7.2/ez_setup.py | python -
curl -k https://raw.github.com/pypa/pip/master/contrib/get-pip.py | python -
pip install pudb==2013.1
The error reported will look something like this:
$ pip install pudb==2013.1
Downloading/unpacking pudb==2013.1
Downloading pudb-2013.1.tar.gz (40kB): 40kB downloaded
Running setup.py egg_info for package pudb
Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.35.tar.gz
Extracting in /tmp/tmpkaEQAq
Now working in /tmp/tmpkaEQAq/distribute-0.6.35
Building a Distribute egg in /home/andreas/mypy/build/pudb
Traceback (most recent call last):
File "setup.py", line 45, in <module>
exec(init_file.read(), d)
File "<string>", line 8, in <module>
File "/tmp/tmpkaEQAq/distribute-0.6.35/setuptools/__init__.py", line 2, in <module>
from setuptools.extension import Extension, Library
File "/tmp/tmpkaEQAq/distribute-0.6.35/setuptools/extension.py", line 5, in <module>
from setuptools.dist import _get_unpatched
File "/tmp/tmpkaEQAq/distribute-0.6.35/setuptools/dist.py", line 6, in <module>
from setuptools.command.install import install
File "/tmp/tmpkaEQAq/distribute-0.6.35/setuptools/command/__init__.py", line 8, in <module>
from setuptools.command import install_scripts
File "/tmp/tmpkaEQAq/distribute-0.6.35/setuptools/command/install_scripts.py", line 3, in <module>
from pkg_resources import Distribution, PathMetadata, ensure_directory
File "/tmp/tmpkaEQAq/distribute-0.6.35/pkg_resources.py", line 2825, in <module>
add_activation_listener(lambda dist: dist.activate())
File "/tmp/tmpkaEQAq/distribute-0.6.35/pkg_resources.py", line 710, in subscribe
callback(dist)
File "/tmp/tmpkaEQAq/distribute-0.6.35/pkg_resources.py", line 2825, in <lambda>
add_activation_listener(lambda dist: dist.activate())
File "/tmp/tmpkaEQAq/distribute-0.6.35/pkg_resources.py", line 2257, in activate
self.insert_on(path)
File "/tmp/tmpkaEQAq/distribute-0.6.35/pkg_resources.py", line 2358, in insert_on
"with distribute. Found one at %s" % str(self.location))
ValueError: A 0.7-series setuptools cannot be installed with distribute. Found one at /home/andreas/mypy/lib/python2.7/site-packages/setuptools-0.7.2-py2.7.egg
/home/andreas/mypy/build/pudb/distribute-0.6.35-py2.7.egg
Traceback (most recent call last):
File "<string>", line 16, in <module>
File "/home/andreas/mypy/build/pudb/setup.py", line 5, in <module>
use_setuptools()
File "distribute_setup.py", line 152, in use_setuptools
return _do_download(version, download_base, to_dir, download_delay)
File "distribute_setup.py", line 132, in _do_download
_build_egg(egg, tarball, to_dir)
File "distribute_setup.py", line 123, in _build_egg
raise IOError('Could not build the egg.')
IOError: Could not build the egg.
Complete output from command python setup.py egg_info:
Downloading http://pypi.python.org/packages/source/d/distribute/distribute-0.6.35.tar.gz
Extracting in /tmp/tmpkaEQAq
Now working in /tmp/tmpkaEQAq/distribute-0.6.35
Building a Distribute egg in /home/andreas/mypy/build/pudb
Traceback (most recent call last):
File "setup.py", line 45, in <module>
exec(init_file.read(), d)
File "<string>", line 8, in <module>
File "/tmp/tmpkaEQAq/distribute-0.6.35/setuptools/__init__.py", line 2, in <module>
from setuptools.extension import Extension, Library
File "/tmp/tmpkaEQAq/distribute-0.6.35/setuptools/extension.py", line 5, in <module>
from setuptools.dist import _get_unpatched
File "/tmp/tmpkaEQAq/distribute-0.6.35/setuptools/dist.py", line 6, in <module>
from setuptools.command.install import install
File "/tmp/tmpkaEQAq/distribute-0.6.35/setuptools/command/__init__.py", line 8, in <module>
from setuptools.command import install_scripts
File "/tmp/tmpkaEQAq/distribute-0.6.35/setuptools/command/install_scripts.py", line 3, in <module>
from pkg_resources import Distribution, PathMetadata, ensure_directory
File "/tmp/tmpkaEQAq/distribute-0.6.35/pkg_resources.py", line 2825, in <module>
add_activation_listener(lambda dist: dist.activate())
File "/tmp/tmpkaEQAq/distribute-0.6.35/pkg_resources.py", line 710, in subscribe
callback(dist)
File "/tmp/tmpkaEQAq/distribute-0.6.35/pkg_resources.py", line 2825, in <lambda>
add_activation_listener(lambda dist: dist.activate())
File "/tmp/tmpkaEQAq/distribute-0.6.35/pkg_resources.py", line 2257, in activate
self.insert_on(path)
File "/tmp/tmpkaEQAq/distribute-0.6.35/pkg_resources.py", line 2358, in insert_on
"with distribute. Found one at %s" % str(self.location))
ValueError: A 0.7-series setuptools cannot be installed with distribute. Found one at /home/andreas/mypy/lib/python2.7/site-packages/setuptools-0.7.2-py2.7.egg
/home/andreas/mypy/build/pudb/distribute-0.6.35-py2.7.egg
Traceback (most recent call last):
File "<string>", line 16, in <module>
File "/home/andreas/mypy/build/pudb/setup.py", line 5, in <module>
use_setuptools()
File "distribute_setup.py", line 152, in use_setuptools
return _do_download(version, download_base, to_dir, download_delay)
File "distribute_setup.py", line 132, in _do_download
_build_egg(egg, tarball, to_dir)
File "distribute_setup.py", line 123, in _build_egg
raise IOError('Could not build the egg.')
IOError: Could not build the egg.
Originally reported by: ncoghlan (Bitbucket: ncoghlan, GitHub: ncoghlan)
Currently setuptools.dist.Distribution passes the unfiltered collection of keyword arguments up to distutils.core.Distribution. This results in lots of scary looking "UserWarning" messages when you actually use the setuptools-only options (see http://stackoverflow.com/questions/8295644/pypi-userwarning-unknown-distribution-option-install-requires)
It also makes it look like you're calling distutils rather than setuptools, since the stack trace (showing that this is a call up into setuptools) isn't visible.
For example, cleaning coverage.py for devinabox looks like this:
[ncoghlan@lancre coveragepy]$ ../cpython/python setup.py clean/home/ncoghlan/devel/devinabox/cpython/Lib/distutils/dist.py:257: UserWarning: Unknown distribution option: 'entry_points'
warnings.warn(msg)
/home/ncoghlan/devel/devinabox/cpython/Lib/distutils/dist.py:257: UserWarning: Unknown distribution option: 'use_2to3'
warnings.warn(msg)
/home/ncoghlan/devel/devinabox/cpython/Lib/distutils/dist.py:257: UserWarning: Unknown distribution option: 'zip_safe'
warnings.warn(msg)
running clean
But if we make those errors, we see that it is picking up the symlinked setuptools correctly:
[ncoghlan@lancre coveragepy]$ ../cpython/python -W error::UserWarning setup.py cleanTraceback (most recent call last):
File "setup.py", line 199, in <module>
main()
File "setup.py", line 188, in main
setup(**setup_args)
File "/home/ncoghlan/devel/devinabox/cpython/Lib/distutils/core.py", line 109, in setup
_setup_distribution = dist = klass(attrs)
File "/home/ncoghlan/devel/devinabox/coveragepy/setuptools/dist.py", line 269, in __init__
_Distribution.__init__(self,attrs)
File "/home/ncoghlan/devel/devinabox/cpython/Lib/distutils/dist.py", line 257, in __init__
warnings.warn(msg)
UserWarning: Unknown distribution option: 'use_2to3'
Originally reported by: jaraco (Bitbucket: jaraco, GitHub: jaraco)
I do regularly run the tests on Windows. Back around 0.6.21 or so, the tests were passing on Windows in totality. When I run the tests now, I get two failures in tests due to shebang lines in scripts (complete transcript):
======================================================================
FAIL: test_get_script_args (setuptools.tests.test_easy_install.TestEasyInstallTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\jaraco\projects\setuptools\setuptools\tests\test_easy_install.py", line 86, in test_get_script_args
self.assertEqual(script, WANTED)
AssertionError: '#!"C:\\Program Files\\Python33\\python.exe"\n# EASY-INSTALL-ENTRY-SCRIPT: \'spe [truncated]... != "#!C:\\Program Files\\Python33\\python.exe\n# EASY-INSTALL-ENTRY-SCRIPT: 'spec', [truncated]...
- #!"C:\Program Files\Python33\python.exe"
? - -
+ #!C:\Program Files\Python33\python.exe
# EASY-INSTALL-ENTRY-SCRIPT: 'spec','console_scripts','name'
__requires__ = 'spec'
import sys
from pkg_resources import load_entry_point
if __name__ == '__main__':
sys.exit(
load_entry_point('spec', 'console_scripts', 'name')()
)
======================================================================
FAIL: test_get_script_header (setuptools.tests.test_resources.ScriptHeaderTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\jaraco\projects\setuptools\setuptools\tests\test_resources.py", line 508, in test_get_script_header
'#!%s\n' % os.path.normpath(sys.executable))
AssertionError: '#!"C:\\Program Files\\Python33\\python.exe"\n' != '#!C:\\Program Files\\Python33\\python.exe\n'
- #!"C:\Program Files\Python33\python.exe"
? - -
+ #!C:\Program Files\Python33\python.exe
----------------------------------------------------------------------
I've been ignoring these test failures because I believe it is the tests that are broken and not the implementation. I suspect these tests will not fail when there is not a space in the path to python.exe.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.