Now that PEP 621 support has been merged in https://github.com/pypa/setuptools/pull/2970, we can move project metadata into pyproject.toml and get rid of setup.py and setup.cfg.

The one 'regression' is that external data files are deprecated (https://setuptools.pypa.io/en/latest/userguide/datafiles.html) so support has been removed here.

This should remain a draft PR until https://github.com/pypa/setuptools/issues/2816 is resolved and editable installs work.

Closes #56, closes #57, closes #96.

I have tried this on Python 2.7.5 and Python 3.4.3 and am unable to see package_data.dat or data_file installed anywhere when I do "python setup.py install" If I change to distutils it works fine.

In commit 335acdcd, setup.py was made to import the very package it's meant to install. [There are issues with importing the package itself during installation, see Carl Meyer's post here (referenced in Issue #1) and a leading answer on Stack Overflow here.

Looking at the setuptools documentation, it seems that it's now possible to put project's metadata in setup.cfg (see http://setuptools.readthedocs.io/en/latest/setuptools.html#configuring-setup-using-setup-cfg-files). I don't know when this was introduced, but would it make sense to switch to this approach as the recommended method?

@jaraco Any comments? I don't know when this ability was introduced to setuptools, but it looks really easy to use, and (as far as I'm aware) didn't get as much publicity as maybe it should have...?

An example is at:

https://github.com/pydata/pandas-datareader/blob/master/setup.py#L17

Please let me know if you are open to a PR updating setup.py as above.

Initially, I thought a file with the name LICENSE.txt would be included by default.

Before:

$ python setup.py bdist_wheel
...
$ python setup.py bdist_wheel
adding 'sample\__init__.py'
adding 'sample\package_data.dat'
adding 'sampleproject-1.2.0.data\data\my_data\data_file'
adding 'sampleproject-1.2.0.dist-info\DESCRIPTION.rst'
adding 'sampleproject-1.2.0.dist-info\entry_points.txt'
adding 'sampleproject-1.2.0.dist-info\metadata.json'
adding 'sampleproject-1.2.0.dist-info\top_level.txt'
adding 'sampleproject-1.2.0.dist-info\WHEEL'
adding 'sampleproject-1.2.0.dist-info\METADATA'
adding 'sampleproject-1.2.0.dist-info\RECORD'

After:

$ python setup.py bdist_wheel
...
adding 'sample\__init__.py'
adding 'sample\package_data.dat'
adding 'sampleproject-1.2.0.data\data\my_data\data_file'
adding 'sampleproject-1.2.0.dist-info\DESCRIPTION.rst'
adding 'sampleproject-1.2.0.dist-info\LICENSE.txt'
adding 'sampleproject-1.2.0.dist-info\entry_points.txt'
adding 'sampleproject-1.2.0.dist-info\metadata.json'
adding 'sampleproject-1.2.0.dist-info\top_level.txt'
adding 'sampleproject-1.2.0.dist-info\WHEEL'
adding 'sampleproject-1.2.0.dist-info\METADATA'
adding 'sampleproject-1.2.0.dist-info\RECORD'

Currently the setup.py file says to choose a license but doesn't give a hint as to what type of value should go in the license argument.

This patch adds to the comment a link to the Software Package Data Exchange license list which is where the license values are standardized.

We should probably flesh out the tests directory a bit (although it's going to be hard to avoid getting into "my favourite test package" debates...)

• Does the tests directory need __init__.py? (Yes, for some test tools, so probably should be there).
• How are tests run? Will setup.py test work? Does anyone actually use that? Should we include a (cross-platform) test runner script?
• Do we need a note in README.txt recommending pip install -e when running tests, or should the test runner script just set sys.path?

I think we probably should recommend a testing package, specifically unittest. It's another one of those "give a basic recommendation that people can evaluate once they have experience" issues.

We need to sort out getting the tests directory into the sdist. The MANIFEST.in has a stab at it, but I'm not sure it works. I raised a question about this on pypa-dev (in the long thread on this project) but didn't get a satisfactory answer...

It would be useful if the sample setup.py demonstrated how to use python_requires to describe the versions of Python your project supports.

I understand python_requires is a new feature of Pip, but I didn't realise it existed: I actually assumed that Pip used the Programming Lange :: Python classifiers to determine the Python versions supported, and published a "Python3-only" package which was still installable on Python 2 as a result.

It'd be useful if the sample demonstrated python_requires, and clarified that the classifiers are recommendations only (for humans to read), while python_requires is actually checked by Pip before installing.

many people use tox and travis, right?

maybe this is "feature creep" for the point of this project, but I don't know.
I'm inclined to add it.

Hi!

Thank you for the good work on this package.

When I am trying to follow the example, it pops an error.

from candlestick import candlestick df = candlestick.inverted_hammer(df, target='result')

Can you please help me with this issue? Thank you.

(Python3.8 in Windows.)

Traceback (most recent call last): File "C:\My Documents\Scripts\WSS 20200323\G.py", line 8, in <module> df = candlestick.inverted_hammer(df, target='result') File "C:\Python38\lib\site-packages\candlestick\candlestick.py", line 138, in inverted_hammer cndl = __create_object('InvertedHammer', target) File "C:\Python38\lib\site-packages\candlestick\candlestick.py", line 35, in __create_object return __get_class_by_name(class_name)(target=target) File "C:\Python38\lib\site-packages\candlestick\candlestick.py", line 27, in __get_class_by_name module = __load_module(mod_name) File "C:\Python38\lib\site-packages\candlestick\candlestick.py", line 19, in __load_module raise e File "C:\Python38\lib\site-packages\candlestick\candlestick.py", line 16, in __load_module module = __import__(module_path, fromlist=[super_module], level=0) ModuleNotFoundError: No module named 'candlestick.patterns' [Finished in 1.8s]

Both python tests/test_simple.py and python -m unittest discover throw errors because of the import

  File "sampleproject/tests/test_simple.py", line 7, in <module>
    from sample.simple import add_one
ModuleNotFoundError: No module named 'sample'

So what's the correct way to test this package and other packages while in development?

When I try to run an installed version of the sample script I get the error

Traceback (most recent call last):
  File "/home/bradbell/prefix/sampleproject/bin/sample", line 33, in <module>
    sys.exit(load_entry_point('sampleproject==2.0.0', 'console_scripts', 'sample')())
  File "/home/bradbell/prefix/sampleproject/bin/sample", line 22, in importlib_load_entry_point
    for entry_point in distribution(dist_name).entry_points
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 919, in distribution
    return Distribution.from_name(distribution_name)
  File "/usr/lib64/python3.10/importlib/metadata/__init__.py", line 518, in from_name
    raise PackageNotFoundError(name)
importlib.metadata.PackageNotFoundError: No package metadata was found for sampleproject

Steps to reproduce:

1. git clone https://github.com/pypa/sampleproject/ sampleproject.git
2. cd sampelproject.git
3. python setup.py install --prefix=$HOME/prefix/sampleproject
4. program=$(find $HOME/prefix/sampleproject -name sample)
5. pylib=$(find $HOME/prefix/sampleproject -name site-packages)
6. export PYTHONPATH="$pylib:$PYTHONPATH"
7. $program

__main__.py is frequently used by packages and modules (like the standard turtledemo) to enable things like:

python -m some_module

I would like to propose a __main__.py example inside src/sampleproject, as a reference for new developers. I know that any change must be documented, but I don't think it would be really hard to do.

Also, if you like this idea, tell me, and I can open a pull request.

pypa/sampleproject and Python Packaging User Guide's "Packaging Python Projects" page suggest the unit test folder be named tests. But by default, all files matching the pattern test/test*.py, not tests/test*.py, are included in the source distribution. Indeed, I renamed tests to test in sampleproject, then python setup.py sdist bdist_wheel will create a dist package that includes test/test*.py.

Or, did sampleproject intentionally change the name to avoid sdist's inclusion of the test files? That'd be a weird way to do so. It would be better to rename it back to test and explicitly put an exclude line in MANIFEST.in if you want the exclusion.

it's more a question than a real issue, I know there are some alternatives based on cookiecutter for example, but can this be taked as a good starting point, or only serves as a reference for the Python Packaging Tutorial.

Thanks.