I'm curious about the following situation. Let's say I have two projects named project_alpha and project_bravo, both defining a top-level namespace package mymeta. The layout:
project_alpha/
-> mymeta/
-> __init__.py
-> project_alpha/
-> __init__.py
-> version.py
-> setup.py
project_bravo/
-> mymeta/
-> __init__.py
-> project_bravo/
-> __init__.py
-> version.py
-> setup.py
Both mymeta/__init__.pys contain only the line __import__('pkg_resources').declare_namespace(__name__) (according to namespace section in setuptools docs). Contents of both version.pys:
__version_info__ = (0, 9, 9, 'dev0')
__version__ = '.'.join((str(entry) for entry in __version_info__))
The setup.py script for project_alpha is pretty simple. The namespace package mymeta is declared, and the version is taken from the version module:
# project_alpha
from setuptools import find_packages, setup
from mymeta.project_alpha.version import __version__
setup(
name='mymeta.project-alpha',
version=__version__,
namespace_packages=['mymeta'],
packages=find_packages(),
)
The setup.py script for project_bravo has the same structure, but with a twist: project_bravo depends on project_alpha when building:
from setuptools import find_packages, setup
from mymeta.project_bravo.version import __version__
setup(
name='mymeta.project-bravo',
version=__version__,
namespace_packages=['mymeta'],
setup_requires=['mymeta.project-alpha'],
packages=find_packages(),
)
When building project_bravo, I get the following error:
~/project_bravo $ python setup.py sdist
Traceback (most recent call last):
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/sandbox.py", line 156, in save_modules
yield saved
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/sandbox.py", line 197, in setup_context
yield
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/sandbox.py", line 246, in run_setup
DirectorySandbox(setup_dir).run(runner)
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/sandbox.py", line 276, in run
return func()
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/sandbox.py", line 245, in runner
_execfile(setup_script, ns)
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/sandbox.py", line 47, in _execfile
exec(code, globals, locals)
File "/tmp/easy_install-ahmxos98/mymeta.project-alpha-0.9.9.dev0/setup.py", line 6, in <module>
try:
ImportError: No module named 'mymeta.project_alpha'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "setup.py", line 22, in <module>
packages=find_packages(),
File "/usr/lib64/python3.5/distutils/core.py", line 108, in setup
_setup_distribution = dist = klass(attrs)
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/dist.py", line 315, in __init__
self.fetch_build_eggs(attrs['setup_requires'])
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/dist.py", line 361, in fetch_build_eggs
replace_conflicting=True,
File "/tmp/tstenv/lib/python3.5/site-packages/pkg_resources/__init__.py", line 853, in resolve
dist = best[req.key] = env.best_match(req, ws, installer)
File "/tmp/tstenv/lib/python3.5/site-packages/pkg_resources/__init__.py", line 1125, in best_match
return self.obtain(req, installer)
File "/tmp/tstenv/lib/python3.5/site-packages/pkg_resources/__init__.py", line 1137, in obtain
return installer(requirement)
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/dist.py", line 429, in fetch_build_egg
return cmd.easy_install(req)
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/command/easy_install.py", line 665, in easy_install
return self.install_item(spec, dist.location, tmpdir, deps)
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/command/easy_install.py", line 695, in install_item
dists = self.install_eggs(spec, download, tmpdir)
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/command/easy_install.py", line 876, in install_eggs
return self.build_and_install(setup_script, setup_base)
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/command/easy_install.py", line 1115, in build_and_install
self.run_setup(setup_script, setup_base, args)
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/command/easy_install.py", line 1101, in run_setup
run_setup(setup_script, args)
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/sandbox.py", line 249, in run_setup
raise
File "/usr/lib64/python3.5/contextlib.py", line 77, in __exit__
self.gen.throw(type, value, traceback)
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/sandbox.py", line 197, in setup_context
yield
File "/usr/lib64/python3.5/contextlib.py", line 77, in __exit__
self.gen.throw(type, value, traceback)
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/sandbox.py", line 168, in save_modules
saved_exc.resume()
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/sandbox.py", line 143, in resume
six.reraise(type, exc, self._tb)
File "/tmp/tstenv/lib/python3.5/site-packages/pkg_resources/_vendor/six.py", line 685, in reraise
raise value.with_traceback(tb)
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/sandbox.py", line 156, in save_modules
yield saved
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/sandbox.py", line 197, in setup_context
yield
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/sandbox.py", line 246, in run_setup
DirectorySandbox(setup_dir).run(runner)
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/sandbox.py", line 276, in run
return func()
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/sandbox.py", line 245, in runner
_execfile(setup_script, ns)
File "/tmp/tstenv/lib/python3.5/site-packages/setuptools/sandbox.py", line 47, in _execfile
exec(code, globals, locals)
File "/tmp/easy_install-ahmxos98/mymeta.project-alpha-0.9.9.dev0/setup.py", line 6, in <module>
try:
ImportError: No module named 'mymeta.project_alpha'
Unfortunately, I don't understand the error here. It has something to do with the imports order, right? If I comment out the import of mymeta.project_bravo.version in project_bravo/setup.py and replace the version with some hard-coded string, suddenly the build succeeds...
Edit: I introduced a workaround for this issue. Instead of trying to import the version directly, I exec the version module to avoid the import problems. Of course, this is not a proper solution, thus not posting this as answer, but still here it is:
__version__ = None # if the exec fails, leave the version unset, the resulting build version will be 0.0.0
version_script_path = os.path.relpath(os.path.join(os.path.dirname(__file__), 'mymeta', 'project_alpha', 'version.py'))
with open(version_script_path) as version_script:
exec(version_script.read())
After the version script is read and executed, the version is initialized, thus no need to import anything from mymeta package.
Almost one year later, I once again faced this issue and the solution for python>=3.3 is to use implicit namespace packages as specified in PEP 420. The project structure is barely changed, just both the __init__.pys for pkgutil-style namespace package mymeta are gone:
project_alpha/
-> mymeta/
-> project_alpha/
-> __init__.py
-> version.py
-> setup.py
project_bravo/
-> mymeta/
-> project_bravo/
-> __init__.py
-> version.py
-> setup.py
To make setuptools happy, both setup scripts need to be adjusted as well:
...
setup(
...
packages=['mymeta.' + pkg for pkg in find_packages('mymeta')],
)
Now the imports will be resolved correctly when building project-bravo.
As mentioned in the comments: The command
$ python setup.py sdist
for mymeta.project_bravo downloads an egg of mymeta.project_alpha from a private pypi repo.
Namespace packages are very delicate concerning their imports.
e.g. I found out that when I install ns.a and ns.b regularly in my environment and supply the import path of ns.d in a .pth file in the site-packages directory, it will not work, no matter what. However when I symlink to ns.d in site-packeges/ns directory it will work.
If I install none of the components and supply all paths in a .pth in the site-packages directory, everything works fine.
If I install all of the components regularly also everything works fine.
Just when I mix concepts it will not work.
Therefore I suspect that this might also be the issue here: Different strategies for the import paths.
You might want to try to modify your __init__.py file to:
from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)
__import__('pkg_resources').declare_namespace(__name__)
I regret my decision to do namespace packages. I would never do it again.
Related
Getting the following error when trying to build my application. My code runs smoothly inside VScode (running the python file directly). I've looked online and I can't seem to find anyone who's had this error pop up. It used to happen to me when I wasn't in my virtual environment, but I definitely am now (source venv/bin/activate). What could it be? Thanks
Traceback (most recent call last):
File "/Users/wiggly/Desktop/twitterBot/setup.py", line 14, in <module>
setup(
^^^^^^
File "/Users/wiggly/Desktop/twitterBot/venv/lib/python3.11/site-packages/setuptools/__init__.py", line 153, in setup
return distutils.core.setup(**attrs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/distutils/core.py", line 148, in setup
dist.run_commands()
^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/distutils/dist.py", line 966, in run_commands
self.run_command(cmd)
^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/distutils/dist.py", line 985, in run_command
cmd_obj.run()
^^^^^^^^^^^^^
File "/Users/wiggly/Desktop/twitterBot/venv/lib/python3.11/site-packages/py2app/build_app.py", line 967, in run
self._run()
^^^^^^^^^^^
File "/Users/wiggly/Desktop/twitterBot/venv/lib/python3.11/site-packages/py2app/build_app.py", line 1197, in _run
self.run_normal()
^^^^^^^^^^^^^^^^^
File "/Users/wiggly/Desktop/twitterBot/venv/lib/python3.11/site-packages/py2app/build_app.py", line 1294, in run_normal
self.process_recipes(mf, filters, flatpackages, loader_files)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/wiggly/Desktop/twitterBot/venv/lib/python3.11/site-packages/py2app/build_app.py", line 1143, in process_recipes
rval = check(self, mf)
^^^^^^^^^^^^^^^
File "/Users/wiggly/Desktop/twitterBot/venv/lib/python3.11/site-packages/py2app/recipes/detect_dunder_file.py", line 54, in check
scan_bytecode_loads(names, node.code)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/wiggly/Desktop/twitterBot/venv/lib/python3.11/site-packages/py2app/recipes/detect_dunder_file.py", line 31, in scan_bytecode_loads
scan_bytecode_loads(names, c)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/wiggly/Desktop/twitterBot/venv/lib/python3.11/site-packages/py2app/recipes/detect_dunder_file.py", line 25, in scan_bytecode_loads
name = co.co_names[inst.arg]
~~~~~~~~~~~^^^^^^^^^^
IndexError: tuple index out of range
I use the default setup.py using the command provided in the docs py2applet --make-setup bot.py
"""
This is a setup.py script generated by py2applet
Usage:
python setup.py py2app
"""
from setuptools import setup
APP = ["bot.py"]
DATA_FILES = []
OPTIONS = {}
setup(
app=APP,
data_files=DATA_FILES,
options={"py2app": OPTIONS},
setup_requires=["py2app"],
)
The problem is that you have installed a beta version of Python (version 3.11). And looks like py2app version 0.28.2 is not compatible with it. Try to uninstall the 3.11 version and install the current release version 3.10 and it should work. Also, recreate the virtual environment after you install it because the current one would still be pointing to the 3.11 version.
I've been using cxFreeze to build my Python code for some time and had no issue, until today. I'm not sure the problem comes from cxFreeze, though. Although there are some RuntimeError exceptions on the web, they don't exactly match what I obtain.
$ python2.7 setup.py build
running build
running build_exe
Traceback (most recent call last):
File "setup.py", line 79, in <module>
executables = [client, updater, dbg_updater]
File "C:\python27\lib\site-packages\cx_Freeze\dist.py", line 362, in setup
distutils.core.setup(**attrs)
File "C:\python27\lib\distutils\core.py", line 151, in setup
dist.run_commands()
File "C:\python27\lib\distutils\dist.py", line 953, in run_commands
self.run_command(cmd)
File "C:\python27\lib\distutils\dist.py", line 972, in run_command
cmd_obj.run()
File "C:\python27\lib\distutils\command\build.py", line 127, in run
self.run_command(cmd_name)
File "C:\python27\lib\distutils\cmd.py", line 326, in run_command
self.distribution.run_command(command)
File "C:\python27\lib\distutils\dist.py", line 972, in run_command
cmd_obj.run()
File "C:\python27\lib\site-packages\cx_Freeze\dist.py", line 232, in run
freezer.Freeze()
File "C:\python27\lib\site-packages\cx_Freeze\freezer.py", line 619, in Freeze
self.finder = self._GetModuleFinder()
File "C:\python27\lib\site-packages\cx_Freeze\freezer.py", line 378, in _GetModuleFinder
finder.IncludePackage(name)
File "C:\python27\lib\site-packages\cx_Freeze\finder.py", line 686, in IncludePackage
module = self._ImportModule(name, deferredImports)
File "C:\python27\lib\site-packages\cx_Freeze\finder.py", line 346, in _ImportModule
deferredImports, namespace = namespace)
File "C:\python27\lib\site-packages\cx_Freeze\finder.py", line 419, in _InternalImportModule
namespace = namespace)
File "C:\python27\lib\site-packages\cx_Freeze\finder.py", line 436, in _InternalImportModule
parentModule, namespace)
File "C:\python27\lib\site-packages\cx_Freeze\finder.py", line 448, in _LoadModule
namespace)
File "C:\python27\lib\site-packages\cx_Freeze\finder.py", line 513, in _LoadPackage
self._LoadModule(name, fp, path, info, deferredImports, parent)
File "C:\python27\lib\site-packages\cx_Freeze\finder.py", line 502, in _LoadModule
self._ScanCode(module.code, module, deferredImports)
File "C:\python27\lib\site-packages\cx_Freeze\finder.py", line 601, in _ScanCode
module, relativeImportIndex)
......................................
File "C:\python27\lib\site-packages\cx_Freeze\finder.py", line 356, in _ImportModule
deferredImports, namespace = namespace)
File "C:\python27\lib\site-packages\cx_Freeze\finder.py", line 436, in _InternalImportModule
parentModule, namespace)
File "C:\python27\lib\site-packages\cx_Freeze\finder.py", line 502, in _LoadModule
self._ScanCode(module.code, module, deferredImports)
File "C:\python27\lib\site-packages\cx_Freeze\finder.py", line 601, in _ScanCode
module, relativeImportIndex)
File "C:\python27\lib\site-packages\cx_Freeze\finder.py", line 356, in _ImportModule
deferredImports, namespace = namespace)
File "C:\python27\lib\site-packages\cx_Freeze\finder.py", line 436, in _InternalImportModule
parentModule, namespace)
File "C:\python27\lib\site-packages\cx_Freeze\finder.py", line 449, in _LoadModule
module = self._AddModule(name)
File "C:\python27\lib\site-packages\cx_Freeze\finder.py", line 213, in _AddModule
module = self._modules[name] = Module(name)
RuntimeError: maximum recursion depth exceeded while calling a Python object
No idea what is creating the bug. I didn't add in any new module and just fixed some errors in my program. I have the most recent version of pip and setuptools. Does anyone know what this error mean?
If you want to see the code, it's here: https://github.com/vlegoff/cocomud/blob/master/src/setup.py
Thanks in advance!
EDIT:
It turned out all the fuss was because of the parse module (pypi.python.org/pypi/parse), although it's not included in the project I was trying to freeze. I removed it with pip uninstall and it worked when I tried to freeze my project. No idea why, I did it because I remember having installed two new packages to try them out.
This looks strange. I believe it could be related to a bug in cx_freeze.
If you read the people referred by this link:
https://bitbucket.org/anthony_tuininga/cx_freeze/issues/184/importing-pyqtgraph-causes-recursion-limit
They seem to have a problem with pyqtgraph, but also with urllib, that you are using in your project (and the bug doesn't seems fixed yet). So I suggest to exclude this from your project and to check if this works better. Maybe, you could also try another version of cx_freeze, or specifying the imported libraries in another way, for instance, by linking modules manually using this syntax:
Buildoptions=dict(
compressed=True,
includes=["moduletoinclude"],
path=sys.path + ["Lib"]
)
Have a nice day
It turned out all the fuss was because of the parse module (pypi.python.org/pypi/parse), although it's not included in the project I was trying to freeze. I removed it with pip uninstall and it worked when I tried to freeze my project. No idea why, I did it because I remember having installed two new packages to try them out.
So I have a script called papercutter.py and a setup.py that is set up as follows according to the py2exe tutorial:
from distutils.core import setup
import py2exe
setup(console=['papercutter.py'])
So following the tutorial, i run python setup.py py2exe and it looks successful:
c:\Codes>python setup.py install
running install
running build
running install_egg_info
Removing C:\Python\Lib\site-packages\UNKNOWN-0.0.0-py3.6.egg-info
Writing C:\Python\Lib\site-packages\UNKNOWN-0.0.0-py3.6.egg-info
but when I run the next step, python setup.py py2exe, I get error:
c:\Codes>python setup.py py2exe
running py2exe
Traceback (most recent call last):
File "setup.py", line 4, in <module>
setup(console=['papercutter.py'])
File "C:\Python\lib\distutils\core.py", line 148, in setup
dist.run_commands()
File "C:\Python\lib\distutils\dist.py", line 955, in run_commands
self.run_command(cmd)
File "C:\Python\lib\distutils\dist.py", line 974, in run_command
cmd_obj.run()
File "C:\Python\lib\site-packages\py2exe\distutils_buildexe.py", line 188, in run
self._run()
File "C:\Python\lib\site-packages\py2exe\distutils_buildexe.py", line 267, in _run
builder.analyze()
File "C:\Python\lib\site-packages\py2exe\runtime.py", line 157, in analyze
self.mf.import_package(modname[:-2])
File "C:\Python\lib\site-packages\py2exe\mf3.py", line 91, in import_package
self.import_hook(name)
File "C:\Python\lib\site-packages\py2exe\mf3.py", line 117, in import_hook
module = self._gcd_import(name)
File "C:\Python\lib\site-packages\py2exe\mf3.py", line 267, in _gcd_import
return self._find_and_load(name)
File "C:\Python\lib\site-packages\py2exe\mf3.py", line 320, in _ find_and_load
self._scan_code(module.__code__, module)
File "C:\Python\lib\site-packages\py2exe\mf3.py", line 352, in _scan_code
for what, args in self._scan_opcodes(code):
File "C:\Python\lib\site-packages\py2exe\mf3.py", line 381, in _scan_opcodes
yield "store", (names[oparg],)
IndexError: tuple index out of range
What am I doing wrong here?
Note: this is the tutorial I am following: http://www.py2exe.org/index.cgi/Tutorial
Also note: I am using py2exe 0.9.2.0 and python 3.6.0. I think these should be fine together.
The answer is at the bottom of the Traceback. Seems like you have an indexing problem with a tuple. Indexes are 0 based in Python.
Currently py2exe supports Python up to 3.4
My package depends on BeautifulSoup. If I install my package in a fresh virtualenv via python setup.py develop, I get the following error. If I execute python setup.py develop a second time, everything seems to work fine. I have no idea, what's happening. How to fix it to get a reproducable setup?
Best match: beautifulsoup4 4.3.2
Downloading https://pypi.python.org/packages/source/b/beautifulsoup4/beautifulsoup4-4.3.2.tar.gz#md5=b8d157a204d56512a4cc196e53e7d8ee
Processing beautifulsoup4-4.3.2.tar.gz
Writing /tmp/easy_install-1eBfi3/beautifulsoup4-4.3.2/setup.cfg
Running beautifulsoup4-4.3.2/setup.py -q bdist_egg --dist-dir /tmp/easy_install-1eBfi3/beautifulsoup4-4.3.2/egg-dist-tmp-YmoFSq
Traceback (most recent call last):
File "setup.py", line 73, in <module>
""",
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 "/home/domma/VirtualEnvs/orcid/local/lib/python2.7/site-packages/setuptools/command/develop.py", line 27, in run
self.install_for_development()
File "/home/domma/VirtualEnvs/orcid/local/lib/python2.7/site-packages/setuptools/command/develop.py", line 129, in install_for_development
self.process_distribution(None, self.dist, not self.no_deps)
File "/home/domma/VirtualEnvs/orcid/local/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 671, in process_distribution
[requirement], self.local_index, self.easy_install
File "/home/domma/VirtualEnvs/orcid/local/lib/python2.7/site-packages/pkg_resources.py", line 564, in resolve
dist = best[req.key] = env.best_match(req, self, installer)
File "/home/domma/VirtualEnvs/orcid/local/lib/python2.7/site-packages/pkg_resources.py", line 802, in best_match
return self.obtain(req, installer) # try and download/install
File "/home/domma/VirtualEnvs/orcid/local/lib/python2.7/site-packages/pkg_resources.py", line 814, in obtain
return installer(requirement)
File "/home/domma/VirtualEnvs/orcid/local/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 593, in easy_install
return self.install_item(spec, dist.location, tmpdir, deps)
File "/home/domma/VirtualEnvs/orcid/local/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 623, in install_item
dists = self.install_eggs(spec, download, tmpdir)
File "/home/domma/VirtualEnvs/orcid/local/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 809, in install_eggs
return self.build_and_install(setup_script, setup_base)
File "/home/domma/VirtualEnvs/orcid/local/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 1015, in build_and_install
self.run_setup(setup_script, setup_base, args)
File "/home/domma/VirtualEnvs/orcid/local/lib/python2.7/site-packages/setuptools/command/easy_install.py", line 1000, in run_setup
run_setup(setup_script, args)
File "/home/domma/VirtualEnvs/orcid/local/lib/python2.7/site-packages/setuptools/sandbox.py", line 50, in run_setup
lambda: execfile(
File "/home/domma/VirtualEnvs/orcid/local/lib/python2.7/site-packages/setuptools/sandbox.py", line 100, in run
return func()
File "/home/domma/VirtualEnvs/orcid/local/lib/python2.7/site-packages/setuptools/sandbox.py", line 52, in <lambda>
{'__file__':setup_script, '__name__':'__main__'}
File "setup.py", line 27, in <module>
'raven',
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 970, in run_command
cmd_obj = self.get_command_obj(command)
File "/usr/lib/python2.7/distutils/dist.py", line 846, in get_command_obj
cmd_obj = self.command_obj[command] = klass(self)
File "/home/domma/VirtualEnvs/orcid/local/lib/python2.7/site-packages/setuptools/__init__.py", line 69, in __init__
_Command.__init__(self,dist)
File "/usr/lib/python2.7/distutils/cmd.py", line 59, in __init__
raise TypeError, "dist must be a Distribution instance"
TypeError: dist must be a Distribution instance
This error has to do with a discrepancy between the versions of distutils and setuptools installed on your machine. Upgrading setuptools to the current version is likely to resolve the issue.
EDIT: This solution no longer works for me (and apparently never worked for Jens -- see comment below). What now works for me is to import setuptools before anything else in whatever script I'm calling that leads to this error.
This error is discussed in many issues on GitHub, in many packages, but I find this discussion to be the most informative.
The only way I was able to solve it was to follow the https://bugs.python.org/file37554/distutils_accomodate_distribution_ducktypes.patch
So - I removed /usr/lib/python2.7/distutils/cmd.py and /usr/lib/python2.7/distutils/cmd.pyc ( ran a python setup.py develop - just to make sure it fails and is not using the pyc from somewhere else ) and then recreated /usr/lib/python2.7/distutils/cmd.py - only this time with the changes as shown in the patch. Then when I used python setup.py again - it worked..
install dnspython. pip install dnspython. Or check if u have older version of dnspython and upgrade
Try using pip for installing your package
$ pip install -e path/to/your/Project
See http://pip.readthedocs.org/en/latest/reference/pip_install.html#editable-installs for more information.
When I encountered this, it appeared at first glance that it was complaining that Distribution() didn't produce a Distribution instance, but that was only partly true.
setuptools provides its own Distribution, and monkeypatches it into distutils. That works in most cases, but will fail if you get a reference to Distribution before setuptools has been imported and done its magic.
The top of the script read:
from distutils.dist import Distribution
and then later we were importing and using various parts of setuptools.
The solution in my case was to do a late import in the function that uses it so Distribution was obtained after setuptools was loaded.
I'm not sure I'm organizing my package structure correctly or am using the right options in setup.py because I'm getting errors when I try to run unit tests.
I have a structure like this:
/project
/bin
/src
/pkgname
__init__.py
module1.py
module2.py
/tests
__init__.py
test1.py
test2.py
My setup.py looks like this:
#!/usr/bin/env python
from setuptools import setup, find_packages
setup(version='0.1',
description='Trend following library',
author='Nate Reed',
author_email='nate#natereed.com',
packages=find_packages(),
install_requires=['numpy'],
test_suite="tests",
)
When I run 'python setup.py test' I get:
nate#nate-desktop:~/PycharmProjects/trendfollowing$ sudo python setup.py test
running test
running egg_info
writing requirements to UNKNOWN.egg-info/requires.txt
writing UNKNOWN.egg-info/PKG-INFO
writing top-level names to UNKNOWN.egg-info/top_level.txt
writing dependency_links to UNKNOWN.egg-info/dependency_links.txt
reading manifest file 'UNKNOWN.egg-info/SOURCES.txt'
writing manifest file 'UNKNOWN.egg-info/SOURCES.txt'
running build_ext
Traceback (most recent call last):
File "setup.py", line 11, in <module>
test_suite="tests",
File "/usr/lib/python2.6/distutils/core.py", line 152, in setup
dist.run_commands()
File "/usr/lib/python2.6/distutils/dist.py", line 975, in run_commands
self.run_command(cmd)
File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
cmd_obj.run()
File "/usr/lib/python2.6/dist-packages/setuptools/command/test.py", line 137, in run
self.with_project_on_sys_path(self.run_tests)
File "/usr/lib/python2.6/dist-packages/setuptools/command/test.py", line 117, in with_project_on_sys_path
func()
File "/usr/lib/python2.6/dist-packages/setuptools/command/test.py", line 146, in run_tests
testLoader = loader_class()
File "/usr/lib/python2.6/unittest.py", line 816, in __init__
self.parseArgs(argv)
File "/usr/lib/python2.6/unittest.py", line 843, in parseArgs
self.createTests()
File "/usr/lib/python2.6/unittest.py", line 849, in createTests
self.module)
File "/usr/lib/python2.6/unittest.py", line 613, in loadTestsFromNames
suites = [self.loadTestsFromName(name, module) for name in names]
File "/usr/lib/python2.6/unittest.py", line 587, in loadTestsFromName
return self.loadTestsFromModule(obj)
File "/usr/lib/python2.6/dist-packages/setuptools/command/test.py", line 34, in loadTestsFromModule
tests.append(self.loadTestsFromName(submodule))
File "/usr/lib/python2.6/unittest.py", line 584, in loadTestsFromName
parent, obj = obj, getattr(obj, part)
AttributeError: 'module' object has no attribute 'test1'
Do the test names need to match module names? Are there other conventions I need to follow in my package structure?
Through some trial and error, I found the cause of this problem. Test names should match module names. If there is a "foo_test.py" test, there needs to be a corresponding module foo.py.
I found some guidelines on organizing package structure, which helped me reorganize my package into a structure I was confident in.