4 ms·

I do really like the workflow pipenv provides. But last time I checked, the mayor downside of pipenv is it doesn't and won't support multiple Python versions [0

I do really like the workflow pipenv provides. But last time I checked, the mayor downside of pipenv is it doesn't and won't support multiple Python versions [0]. For libraries, this can be a dealbreaker. For applications, especially ones you're deploying to a controlled environment, this isn't an issue. Been meaning to look into poetry. Not a huge fan of TOML, but hopefully all the tooling supports pyproject.toml now (I know black does, but not sure about flake8, isort, pylint, pytest, coverage). I know there's still some hacks required for tox + poetry though. [0] https://github.com/pypa/pipenv/issues/1050 https://github.com/pypa/pipenv/issues/1050

korijn 7y ago
I use pyenv to switch between python versions (or just the `py` launcher when on windows), and pipenv will follow suit. It does require regeneration of the lockfile for each python version/environment in the scenario you describe, but you can also keep them organized in a folder and swap them out for each environment. You're right that it doesn't come included in the tool though.
ben509 7y ago
It seems like pipenv and poetry fill different niches: pipenv is intended for application deployment, so you're likely to only have one version of python, while poetry is intended for building libraries. I found the tox support a bit hacky, but not bad, and got 3.5 to 3.8 testing just fine. Poetry does make the publishing process pretty seamless for the simple case. If you're starting a new library, poetry is great. I think poetry needs a "fuzz option" to test random valid solutions to the version constraints, to check if the older versions are really valid.
meowface 7y ago
What don't you like about TOML? It seems to be the best language for simple configuration files. I think YAML is often overkill for basic configuration, and JSON isn't ideal. pipenv's Pipfile is also in TOML. What config language would you prefer to use instead?
- guitarbill 7y ago
  To be honest, I don't know. All I can say is YAML parsers exist and it works well enough for many applications, although I do understand the issues with it. Sure, it isn't perfect, but no need to re-invent the wheel for marginal improvements. I roughly agree with the arguments laid out in PEP 518, even though the array of tables thing is not at all "obvious" to me. And I actually do think an "official"/semi-official YAML subset would be great for loads of use-cases - yaml.safe_load already is that in practice.

korijn 7y ago

I use pyenv to switch between python versions (or just the `py` launcher when on windows), and pipenv will follow suit. It does require regeneration of the lockfile for each python version/environment in the scenario you describe, but you can also keep them organized in a folder and swap them out for each environment. You're right that it doesn't come included in the tool though.

ben509 7y ago

It seems like pipenv and poetry fill different niches: pipenv is intended for application deployment, so you're likely to only have one version of python, while poetry is intended for building libraries. I found the tox support a bit hacky, but not bad, and got 3.5 to 3.8 testing just fine. Poetry does make the publishing process pretty seamless for the simple case. If you're starting a new library, poetry is great. I think poetry needs a "fuzz option" to test random valid solutions to the version constraints, to check if the older versions are really valid.

meowface 7y ago

What don't you like about TOML? It seems to be the best language for simple configuration files. I think YAML is often overkill for basic configuration, and JSON isn't ideal. pipenv's Pipfile is also in TOML. What config language would you prefer to use instead?

guitarbill 7y ago
To be honest, I don't know. All I can say is YAML parsers exist and it works well enough for many applications, although I do understand the issues with it. Sure, it isn't perfect, but no need to re-invent the wheel for marginal improvements. I roughly agree with the arguments laid out in PEP 518, even though the array of tables thing is not at all "obvious" to me. And I actually do think an "official"/semi-official YAML subset would be great for loads of use-cases - yaml.safe_load already is that in practice.