Use Poetry workflow

[jgirardet]

Here a small PR using poetry in replacement of requirement.txt, setup.py, twine

I let the scripts because Tom seems to like that.

Small explanations for those who do not know poetry : https://poetry.eustace.io/

About the changes : Everything is stored in the pyproject.toml (pep 518) venv become .venv because poetry auto find .venv virtualenv install optional requirement via -E I have to add toml depedency and tweak a bit __init__ because apistar uses his own version number. This assumes you already have poetry on your sytem (like pip)

[audiolion]

<3 poetry

[jgirardet]

Build it to look at generated setup.py.

[shulcsm]

Why this over pipenv? Seems very opinioned and niche

[jgirardet]

poetry does packaging and pyproject.toml seems to be python future. I totally agree the project is very new

[cb109]

What @shulcsm said, what is the benefit of poety over existing projects like https://github.com/jazzband/pip-tools or https://docs.pipenv.org (the official recommendation)? The page doesn't have a section about this, so I'm actually curious. While it looks great, I assume that regarding adoption of apistar it is a good idea to go with something that is widely in use.

[audiolion]

or https://docs.pipenv.org (the official recommendation)?

This is a huge misconception, PYPA, the Python Packaging Authority, merged a PR back when pipenv was still pretty young that included a doc change saying they recommended it officially. There was a huge amount of controversy, a lot of heated threads and discussions, because the recommendation was basically self-done, Kenneth just said yep I recommend my own project, it wasn't a community decision or one backed by anything other than what felt like a narcissistic action by the creator promoting his own library. I am not taking a side here, just trying to clear some stuff up. After all this controversy Kenneth amended the statement saying it is the recommended tool for applications, and not for libraries, because pipenv was not built for libraries, there is discussion here about it.

tl;dr: pipenv is official recommendation for applications, and it was not designed for building libraries and falls down in this area

what is the benefit of poetry over existing projects like https://github.com/jazzband/pip-tools

Poetry is an existing, established project as well. It was designed to support libraries and meets the use-case well, it takes cognitive overhead off of library maintainers and people who are contributing to the repo by simplifying dependency management.

Anyways, pip still works just fine, and most Python people already know it. Try poetry out and see if you like it, if you do, use it, we don't need to make a holy war out of this, but as for tools to manage this repo, pipenv simply just wasn't built for libraries.

[shulcsm]

@audiolion I'm not advocating pipenv over poetry but i'm against committing to it. "established" seems like a stretch since it has been around for less than a year and seems to have lots of churn.

[cb109]

Thanks for clearing that up, I was referring to this talk https://pyconweb.com/talks/01-07-2018/pipenv-python-dev-workflow-for-humans but did not double check. I can imagine the trouble after such a selfmade recommendation. The application vs library use case is a good point. I am actually pretty happy with virtualenvwrapper + pip-tools myself, but combining their functionality sounds convenient, so am currently looking into pipenv and will do so for poetry as well.

[jgirardet]

This pr was mostly a try, to look what it looks like. I thougt it would be closed for a long day by tom :blush:

[tomchristie]

Thanks for having a look at this. Going to take a pass on either poetry or pipenv.