isabelizimm / cookiecutter-custompy Goto Github PK

Is there a need for automatic versioning? If so--bump-version and versioneer are 2 common approaches. It is also possible to use GitHub Actions to package the latest tag (ge

What is tox.ini?
tldr;
setup.cfg/setup.py are for setuptools, and tox.ini is for tox, but uses setuptools to build the distribution.

Tox, the Python project (not the file), is made to "automate and standardize testing in Python." It creates virtual environments, and installs the configured dependencies for those environments, for the purpose of testing a Python package. A tox.ini, pyproject.toml, and setup.cfg are all ini files.

Questions
Why tox over GitHub Actions? Do we need both? Is everything in tox.ini covered by setup.cfg?

Other resources
[1] https://www.integralist.co.uk/posts/toxini/
[2] https://stackoverflow.com/questions/67098213/is-there-a-reason-to-have-both-tox-ini-and-setup-cfg-in-a-python-project

Considerations:

In general, we would like a flexible way to track dependencies that can be used for a multitude of python versions. This system also needs to ensure that all dependencies are compatible and able to be installed seamlessly.

Options

• Pipfile + Pipfile.lock
  A Pipfile can be used with no particular python version. A Pipfile.lock must have a python version specified. Pipfile.lock ensures dependency compatibility and reproducibility. This is generally used in a single project, but not necessarily used in packaging. For this reason, Pipfiles will NOT be used.

• requirements.txt
  Can have multiple Python versions. Does not guarantee dependency compatibility and reproducibility.

Pandas uses an environment.yml file that autogenerates a requirements-dev.txt

Scikit-learn uses a _min_dependencies.py.

Depending on how the package is built and installed, Python will use setup.py or setup.cfg. I found that I was able to move everything into setup.cfg and then just have setup.py use it, via setuptools. This made behavior of the installed package more consistent.

For example, see: posit-dev/py-htmltools@7c9fffb

Most of the packages we create will be released under MIT, so it would be good to use that as the default.

Also, the current LICENSE file has someone's name in it -- probably best to make it so that name is filled in automatically:

• pytest for testing
• click for CLI
• setup.py (minimal), setup.cfg (verbose), pyproject.toml (minimal) for setup files
• sphinx + mystparser + sphinx_book_theme for docs
• projectname/tests file structure for testing
• github issues templates (include release checklist)
• workflows (docs, testing for 3.7-3.10, codecov)
• bumpversion for versioning
• pre-commit hooks (flake, black, yaml, whitespace)
• Code of Conduct
• MIT license
• maintainers file
• gitignore
• requirements/requirements_dev.txt for CI (if needed?)
• Makefile (builds docs, wheels, installs, tests)

TO ADD:

• release support?

Considerations

In general, we would like a modern but flexible way to set up packages that complies with current PEPs.

Options

• setup.py

• setup.cfg
  Can include most all of what was previously within a setup.py file.

• pyproject.toml PEP 517
  This file is needed when using setuptools. The file will expect a [build-system] to store build-related information.

References