Support for PEP 517 and 518, Poetry; dependence on setuptools

[Neal McBurnett]

Poetry is rapidly gaining traction as a Python dependency management and packaging solution. It has a poetry new command which creates a rudimentary project skeleton (with a --src option to put code under src). And it leverages the provisional standards PEP 517 and 518 to define build systems explicitly, and organize metadata under the new pyproject.toml file.

I don't know if it is too radical for cookiecutter-pylibrary to support the provisional PEPS and/or generating projects that use poetry rather than setuptools. But these days it at least seems appropriate to note the dependence on setuptools more as a choice than a given, and explicitly note lack of support for the provisional PEPs.

And thanks again for this project!

[Ionel Cristian Mărieș]

Just 2 notes here:

1. cookiecutter-pylibrary already adds a pyproject.toml (albeit using a setuptools build-backend) if you enable setuptools-scm (so dependencies are resolved statically)

2. I'm not against poetry but there's a burden to iron all the kinks and support all this template's options. In fact I'm not even sure how cython/cffi/cext options would work with a poetry config - some research required here.

   It's ideal to build an usecase for adding support for poetry - like what problem does it solve? Pretty sure if you go on this line of thought you may find that both cookiecutter-pylibrary and poetry solve the same problem: getting a project up and running easier, without getting stuck intro various setuptools problems. Poetry does it by having fancy configuration and cookiecutter-pylibrary solves it but doing all the tricky boilerplate for you. Sure, poetry does do some fancy dependency management - lets concentrate discussion on that, or whatever else poetry sorely solves (I'm not an expert on poetry tbh). One has to motivate work with something more than hype - like problems being solved.