pypa / setuptools Goto Github PK

Official project repository for the Setuptools build system

Home Page: https://pypi.org/project/setuptools/

License: MIT License

Python 99.02% C 0.96% HTML 0.01% CMake 0.01%

setuptools's Introduction

See the Quickstart and the User's Guide for instructions on how to use Setuptools.

Questions and comments should be directed to GitHub Discussions. Bug reports and especially tested patches may be submitted directly to the bug tracker.

Code of Conduct

Everyone interacting in the setuptools project's codebases, issue trackers, chat rooms, and fora is expected to follow the PSF Code of Conduct.

For Enterprise

Available as part of the Tidelift Subscription.

Setuptools and the maintainers of thousands of other packages are working with Tidelift to deliver one enterprise subscription that covers all of the open source you use.

Learn more.

setuptools's People

Contributors

Stargazers

Watchers

Forkers

rbtcollins wm75 embray helloworld010 ri0t ohnozzy mazhongxin alex ncoghlan mindw dims marx314 brookskindle zyxue gsnedders svdata earthgecko buildout jayvdb digideskio anthrotype thet gforcada blueyed vrde last-g pohlmnar astrojuanlu hashjang benjaoming inirudebwoy wuweichi jenstimmerman spookylukey husoul gitter-badger benoit-pierre irachex smartcrane xavfernandez isnan909 maningmn kikidesign rowillia eliasdorneles minrk saobafei msabramo sileht tharvik vallsv apex1724 dholth gongpu jakirkham sigmavirus24 mx-moth ronnypfannschmidt ofek cod3monk dstufft purg tlandschoff-scale sria91 matejcik leorochael nicoddemus sylvaincorlay robertwb doublek420 theacodes tianlaizhiyin bossjones drownmachine todd-dembrey shahan83 bittner kata198 tweksteen majuscule reaperhulk xin2893 shizihao123 peterwang1205 wjt jinjiacun123 diogobaeder linbing colonelhou cedk goodww1 jmroot 381164016 cachedout preston-landers untitaker plannigan tws0002 davidszotten tanganam

setuptools's Issues

Emit less cryptic error message for a missing namespace package declaration

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:

It found some metadata for that package (and where it found it)
The metadata doesn't say anything about this being a namespace package

See http://stackoverflow.com/questions/13915269/why-do-i-get-userwarning-module-dap-was-already-imported-from-none/ for some background

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/2

SVN 1.7

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:

subversion 1.5 working copy causes problem in entries_finder: NameError: global name 'log' is not defined

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.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/26

2 tests fail in current 0.7.2

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

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/19

Tests not run by setup.py test

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.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/31

Import error in setuptools/ssl_support.py import pkg_resources

Originally reported by: elarson (Bitbucket: elarson, GitHub: elarson)

There is a reference to pkg_resources.resource_filename in setuptools/ssl_support.py, yet the used modules are imported explicitly.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/3

Setuptools 0.7.3 does not install on Python 3.2

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

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/24

TypeError in pkg_resources.resource_stream on Python 3

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

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/32

distribute bugfix for numpy not present in setuptools 0.8

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).

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/33

Two Assertion failures on Windows tests (script_header)

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.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/37

ssl_support.py: 1868:04732ee16e7e broke '_dnsname_to_pat'

Originally reported by: tseaver (Bitbucket: tseaver, GitHub: tseaver)

Dropping the 're' import.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/8

Avoid UserWarnings emitted when calling into distutils.dist.Distribution

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'

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/29

Remove dependency links from metadata

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?

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/47

Pypi home pages of Setuptools and Distribute need to be updated

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.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/13

installation failed on Jython

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?

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/14

setuptools 0.9.1 download link returns 404 Error

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

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/39

Drop support for Python 2.4 and 2.5

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:

context managers
absolute imports

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).

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/41

Downloading setuptools 0.9.6 raised 404 on PyPI.

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.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/45

AttributeError 'NoneType' has no attribute 'group' in package_index

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'

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/42

AttributeError: _dep_map

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

https://bitbucket.org/pypa/setuptools/src/7d2d455b0cd32e95262e5baffcb96bd822340473/pkg_resources.py?at=default#cl-2543

mean? If the code enters require() method, it is always supposed to raise an exception?

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/48

Create a stable & secure hosted link to the latest Setuptools/pip bootstrap script.

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

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/34

Environment marker support fails API tests on PyPy

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.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/50

Broken link to ez_setup.py on overview page(/README?)

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.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/25

AttributeError for _warn_unsafe_extraction in pkg_resources.py

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.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/28

Python 3.0: setup.py install (tip: 2013-06-08)

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'

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/16

Error for setup.py clean in tip 2013-06-08

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

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/15

private http repositories don't work [LookupError: unknown encoding: base64]

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

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/36

ez_setup.py should validate tar file

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

a member is neither a directory nor a regular file (e.g. symlink, device)
member.name starts with '/' or contains '../' in order to prevent directory traversal attacks

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)

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/7

ez_setup.py installs old version of setuptools

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).

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/46

easy_install broke for pypy 1.9 ( 'HASH' object has no attribute 'name')

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'

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/49

distribute_setup.py fails with pkg_resources.VersionConflict

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.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/5

egg_info.get_svn_revision behavior change?

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()

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/20

Python 2.4 compatibility

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

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/21

ez_setup.py should use HTTPS

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.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/10

Authentication against restricted repositories while bootstraping

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

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/27

Default HTTPS PyPI package download failing on Python 2.4.3

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ć

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/22

Disable installation of Windows-specific files on non-Windows systems

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/

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/1

ez_setup.py download and extraction flooding vulnerability

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.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/9

Packages that 'use_setuptools' from older distribute cannot install on setuptools 0.7

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.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/18

atexit error

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

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/38

Remove easy_install

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.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/17

fix winbot/py 2.4.4 bug

Originally reported by: agroszer (Bitbucket: agroszer, GitHub: agroszer)

http://winbot.zope.org/builders/setuptools_master%20py_244_win32/builds/2/steps/test/logs/stdio

ERROR: test_md5 (setuptools.tests.test_packageindex.TestContentCheckers)

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

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/44

Code base modernization

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:

Normalize whitespace and imports
Use Python 3 constructs (where available on Python 2.4)
Use PEP-8 as a guideline for style

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!

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/35

Re-add hashsum check to ez_setup.py

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.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/11

.hg directory should be absent in tarballs

Originally reported by: arfrever (Bitbucket: arfrever, GitHub: arfrever)

.hg directory should be absent in tarballs. It contains some useless junk. release.py should ensure that unversioned files/directories are not included in tarballs.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/23

Need test for ResourceManager.get_cache_path

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.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/30

Setuptools installs as older version

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

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/43

file protection group/world writeable on egg-info files since 0.7x

Originally reported by: Anonymous

since 0.7.x, there are some issues in the tarball setuptools.egg-info directory...namely:

the file protection of the files is group/world writeable (should be group/world read-only)
there are additional .orig files
there is an additional directory EGG-INFO containing an obsolete copy of PKG-INFO.

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

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/40

Update or remove warning when namespace package doesn't use declare_namespace()

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.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/12

A better upgrade path from distribute

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:

Not supply any packages or modules.
Depend on setuptools 0.7.
Allow upgrade over distribute 0.6.
If necessary (I hope it's not), remove the faked setuptools metadata.

This ticket is to explore the viability of such an approach.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/4

pkg_resources merrily adds site-packages to the front of sys.path

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.

Bitbucket: https://bitbucket.org/pypa/setuptools/issue/6

pypa / setuptools Goto Github PK

setuptools's Introduction

Code of Conduct

For Enterprise

setuptools's People

Contributors

Stargazers

Watchers

Forkers

setuptools's Issues

ERROR: test_md5 (setuptools.tests.test_packageindex.TestContentCheckers)

Recommend Projects

Recommend Topics

Recommend Org