The best development in the python packaging field in the last years is the introduction of the setup.cfg:

• declarative description
• simple to read
• easy to diff

It reduces the need for error prone, cargo cult boilerplate code in the setup.py. A nice setup.py should look like this (if it should exist at all):

from setuptools import setup

if __name__ == "__main__":
    setup()

IMHO, the rest should be declaratively described without arbitrary code execution in the setup.cfg

https://github.com/kennethreitz/setup.py/blob/c5a82dc3670b5fa65e4d5da578d992c38b62d524/setup.py#L22

2 years ago I was playing with this http://j.mp/setup_py and one of the features is using pip.req.parse_requirements('requirements.txt') to populate the requires and avoid duplicity.

What do you think about this? on advantage of having a requirements.txt is to use pyup.io and satefy to check updates and audit the requirements for security failures.

FileNotFoundError is not defined in python2

$ python setup.py publish running publish Removing previous builds… Traceback (most recent call last): File "setup.py", line 101, in 'publish': PublishCommand, File "/usr/lib/python2.7/distutils/core.py", line 151, 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 "setup.py", line 60, in run except FileNotFoundError: NameError: global name 'FileNotFoundError' is not defined

I have my directory structure like so

setup.py
MANIFEST.in
LICENSE
README.md
pipfile
pipfile.lock
cryptowatch:
    - cryptowatch
    - __version__.py
    - __init__.py
    - utlitiesFile.py

When I run python setup.py I am given this error:

Traceback (most recent call last):
  File "setup.py", line 25, in <module>
    with open(os.path.join(here, NAME, '__version__.py')) as f:
IOError: [Errno 2] No such file or directory: '/home/fsociety/git/bitbucket/cryptowatch/crypotowatch/__version__.py'

I know I have a file there and I even went as far as making it executable with chmod a+x __version__.py but sill no luck.

Is there something I am doing wrong here?

I have modified the setup.py a little but only information not the actual code, just in case I screwed something up while doing that here it is:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

import codecs
import os
import sys

from setuptools import find_packages, setup

# Package meta-data.
NAME = 'crypotowatch'
DESCRIPTION = 'Track prices and account balaces bitcoin, ethereum, and litecoin'
URL = 'https://github.com/alexanderepstein/cryptowatch'
EMAIL = '[email protected]'
AUTHOR = 'Alexander Epstein'

here = os.path.abspath(os.path.dirname(__file__))

# Import the README and use it as the long-description.
with codecs.open(os.path.join(here, 'README.md'), encoding='utf-8') as f:
    long_description = '\n' + f.read()

# Load the package's __version__.py module as a dictionary.
about = {}
with open(os.path.join(here, NAME, "__version__.py")) as f:
    exec(f.read(), about)

# Support "$ setup.py publish".
if sys.argv[-1] == "publish":
    os.system("python setup.py sdist bdist_wheel upload")
    sys.exit()

# What packages are required for this module to be executed?
required = [
     'requests', 'Adafruit_GPIO'
]

# Dependencies only for versions less than Python 2.7:
# if sys.version_info < (2, 7):
#     required.append('requests[security]')

# Where the magic happens:
setup(
    name=NAME,
    version=about['__version__'],
    description=DESCRIPTION,
    long_description=long_description,
    author=AUTHOR,
    author_email=EMAIL,
    url=URL,
    packages=find_packages(exclude=('tests',)),
#     entry_points={
#         'console_scripts': ['mycli=mymodule:cli'],
#     },
    install_requires=required,
    include_package_data=True,
    license='MIT',
    classifiers=[
        'License :: OSI Approved :: MIT License',
        'Programming Language :: Python',
        'Programming Language :: Python :: 2.6',
        'Programming Language :: Python :: 2.7',
        'Programming Language :: Python :: Implementation :: CPython',
        'Programming Language :: Python :: Implementation :: PyPy'
    ],
)

Perhaps the project could benefit from adding syntax examples for two useful features, commonly seen in the wild:

• extras, e.g. myproj[this,stuff]
• conditional deps, i.e. environment markers (e.g., requiring backports only when needed)

Additionally, I think the UploadCommand thing is feature bloat and should be removed. It doesn't really belong here directly in setup.py, being duplicated in each and every project. Maybe just add a comment or a link to a good guide about how to use twine?

Defaults are important. Most people are just going to copy and paste this and be satisfied that it works after they (probably) change the things they're expected to change. That means it's important to give the user as much of a sense of control over the data they're probably going to change as we can. This PR defines an interface for changing the project's platform support and provides it to the user.

Also, it adds a comment reminding you to change the classifier to match your license if you change the license, because I've already forgotten to do that.

It's probably better to comment out the Python2 classifiers (especially 2.6!) so you only show they're possible, rather than suggest they're desirable as a default.

Check through a small list of likely candidates for README filenames: ['README.rst', 'README.md', 'README.txt', 'README'] and use the first one which exists.

We then infer the long_description_content_type argument from the file extension of the readme file.

Should we point people directly to this? https://packaging.python.org/

The Hitchhiker's guide, although probably a great source of information, is outdated. Written in 2009, the last commit was in 2010.

I believe that given the state of python packaging, it is not a good reference to keep hanging around.

How can we do a nice version bump for major/minor/micro changes?

It might be nice as an extra possible command in setup.py? Would this be possible?

Or do you think it more fits in pipenv?

This PR adds an example notebook that imports the package. This doesn't add much for setup.py repository, but for those using Binder it's nice to have an example since you need a setup.py file to import the package automatically. Currently there is no example for binder (that I can find) that has a setup.py, so this repository seemed like the obvious place to start.

This pull provides 3 options to upload command:

• --test Upload the package to https://test.pypi.org/legacy/ PyPI testing mirror.
• --username=foo Specifies the username used to authenticate uploading the package to PyPI.
• --password=bar Specifies the password used to authenticate uploading the package to PyPI.

Also, I've updated the quotation marks of exclude arguments passed to find_packages option for unify the strings style used in setup.py file.

The readme says the software is in the public domain. This pull request makes the license file match that. Below are further details.

** The readme says the software is in the public domain. The LICENSE file says it is the MIT license.

Neither of these were added by the navdeep, though the master branch seems to now be the one created by ken-reitz who did add these. Additionally, the readme was recently updated by navdeep:

https://github.com/navdeep-G/setup.py/commit/46f7cd41a5d58adde653aae19c54cf689a3b2a91

From the above, I infer that the correct license should be the Unlicense license. I copied and pasted the text from the github template. Presumably, it is the same as the below link.

https://unlicense.org/

Update to resolve pylint conventions and a warning

The below is the results of pylint, pycodestyle, and flake8:

(setup.py) bash-3.2$ pylint setup.py 
************* Module setup
setup.py:1:0: C0114: Missing module docstring (missing-module-docstring)
setup.py:38:0: C0103: Constant name "here" doesn't conform to UPPER_CASE naming style (invalid-name)
setup.py:44:8: C0103: Constant name "long_description" doesn't conform to UPPER_CASE naming style (invalid-name)
setup.py:46:4: C0103: Constant name "long_description" doesn't conform to UPPER_CASE naming style (invalid-name)
setup.py:49:0: C0103: Constant name "about" doesn't conform to UPPER_CASE naming style (invalid-name)
setup.py:51:4: C0103: Constant name "project_slug" doesn't conform to UPPER_CASE naming style (invalid-name)
setup.py:53:8: W0122: Use of exec (exec-used)
setup.py:65:4: C0103: Argument name "s" doesn't conform to snake_case naming style (invalid-name)
setup.py:69:4: C0116: Missing function or method docstring (missing-function-docstring)
setup.py:72:4: C0116: Missing function or method docstring (missing-function-docstring)
setup.py:75:4: C0116: Missing function or method docstring (missing-function-docstring)

------------------------------------------------------------------
Your code has been rated at 7.80/10 (previous run: 7.80/10, +0.00)

(setup.py) bash-3.2$ pycodestyle setup.py 
setup.py:36:80: E501 line too long (81 > 79 characters)
setup.py:83:80: E501 line too long (86 > 79 characters)
setup.py:106:80: E501 line too long (81 > 79 characters)
(setup.py) bash-3.2$ flake8 setup.py 
setup.py:36:80: E501 line too long (81 > 79 characters)
setup.py:83:80: E501 line too long (86 > 79 characters)
setup.py:106:80: E501 line too long (81 > 79 characters)
(setup.py) bash-3.2$

This branch resolves above conventions and a warning as below:

(setup.py) bash-3.2$ pylint setup.py 

-------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 7.80/10, +2.20)

(setup.py) bash-3.2$ pycodestyle setup.py 
(setup.py) bash-3.2$ flake8 setup.py 
(setup.py) bash-3.2$

It would be nice if you also provide .travis.yml for Travis CI. In the script, it should test out a few commands with setup.py such as python setup.py install, etc.