This seems to work but I have questions. Is it generally good practice to mix setuptools and numpy.distribute? Does the order I import them matter? Should I always import setuptools first? Is there an official up-to-date tutorial for packaging extensions to numpy? Perhaps even one with some discussion Fortran extensions? You should not need to … Read more
This seems to get a lot of hits from google, so I thought I’d update for those folks. I was able to do: easy_install –version which produced the output setuptools 3.4.3 I believe this only works for some (newer?) versions of setuptools
You have almost everything you need (even a bit more)! I’d go with the following setup: code.py: foo = 1 __init__.py: from .code import foo Doing a relative import here because __init__.py will be used when importing the whole package. Note that we explicitly mark the import as relative by using the .-syntax because this … Read more
Use environment markers: install_requires=[ ‘threadpool >= 1.2.7; python_version < “3.2.0”‘, ] Setuptools specific usage is detailed in their documentation. The syntax shown above requires setuptools v36.2+ (change log).
[2014-10 TL;DR: distribute is dead, use pip, the new setuptools, and, for binary distributions, wheels. More below.] [Original answer] Distribute is was a fork of the older setuptools so nearly all comments that follow apply equally to Distribute and setuptools. Setuptools was an attempt to fill in a number of holes in the even older … Read more
We also develop software projects that depend on numpy, scipy and other PyPI packages. Hands down, the best tool currently available out there for managing remote installations is zc.buildout. It is very easy to use. You download a bootstrapping script from their website and distribute that with your package. You write a “local deployment” file, … Read more
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.
The section must be [options.entry_points]. See an example at https://github.com/github/octodns/blob/4b44ab14b1f0a52f1051c67656d6e3dd6f0ba903/setup.cfg#L34 [options.entry_points] console_scripts = octodns-compare = octodns.cmds.compare:main octodns-dump = octodns.cmds.dump:main octodns-report = octodns.cmds.report:main octodns-sync = octodns.cmds.sync:main octodns-validate = octodns.cmds.validate:main
According to the documentation, your syntax should work correctly. The documentation states that: setuptools and pkg_resources use a common syntax for specifying a project’s required dependencies. This syntax consists of a project’s PyPI name, optionally followed by a comma-separated list of “extras” in square brackets, optionally followed by a comma-separated list of version specifiers. A … Read more
You could also reverse the dependency: put the version in mylib/__init__.py, parse that file in setup.py to get the version parameter, and use git tag $(setup.py –version) on the command line to create your tag. git tag -a v$(python setup.py –version) -m ‘description of version’ Is there anything more complicated you want to do that … Read more