Live data from Hacker News

Current State of Python Packaging

stefanoborini.com

31–40 of 77 posts

Re: Current State of Python Packaging

#33
post #15

I never heard of poetry before and normally use pipenv. The author states that poetry is more popular than pipenv, is that true? I did a quick comparison: https://github.com/sdispater/poetry watchers: 77 stars: 4,690 forks: 318 https://github.com/pypa/pipenv watchers: 348 stars: 17,207 forks: 1,268 I don't know if the authors statement 'Most people seem to prefer Poetry.' is true.

I never met a single developer who loves pipenv, but everyone had a fatal problem with it at some point.

Re: Current State of Python Packaging

#35

I really hope poetry will win. It's just so good, easy to use and just works.

I like poetry but it comes with 2 problems:

- it uses only pyproject.toml. Despite the current com on this format, it's not stable, it's an incomplete standard and it's not well supported by the ecosystem. Setup.cfg is a much better alternative in the mean time. In fact, just the auto include features make it better.

- there is no nice way to install it. Pip install poetry is the usual one, and it got many gotchas for beginers, which are the ones that would benefit poetry the most.

Re: Current State of Python Packaging

#36
post #29

I'm not sure what Poetry tries this to simplify on the development side... using venv and pip/requirements.txt is simple enough for me. And you don't even have to do it by hand, Pycharm will do it for you and activate the right venv in the shell tab. Distribution is something else, but I wouldn't expect users to type commands in a shell anyway, so there is only a need for one-click installers and/or self contained ex…

In deployment you'll still need to use the command line. Poetry is IDE and OS agnostic.

It manages also the lock file, and resolve deps better than pip.

At last, it lets you put all meta data in one file, including dev deps, then build a wheel.

You can do that with regular setuptool and setup.cfg and it's compatible with pip though.

Re: Current State of Python Packaging

#37
Yet another state of python packaging that:

- skip the explanation on the py command on windows, the version suffixes on unix, -m and why you need to install pip on linux but not on the other OSes.

- doen't address the various sys path issues of pip and poetry. Because at some point you need to install peotry.

- ignore the existence of the excellent and simple setup.cfg.

- ignore the consequences of using poetry on IDE setup, tox or CI.

Python packaging is not hard anymore. But the information you get out there is incomplete and assume some kind of basic sysadmin experience.

Re: Current State of Python Packaging

#38

Yet another state of python packaging that: - skip the explanation on the py command on windows, the version suffixes on unix, -m and why you need to install pip on linux but not on the other OSes. - doen't address the various sys path issues of pip and poetry. Because at some point you need to install peotry. - ignore the existence of the excellent and simple setup.cfg. - ignore the consequences of using poetry on I…

> Python packaging is not hard anymore

Would you tell us which is "the right way to do it" nowadays? Possibly, in a maintainable, kind-of-officially supported way that doesn't change or disappear in a few months?

Please note: I use Python professionally since 2005, I've been involved a lot in Python packaging for production apps (including giving some talks on the bad state of Python packaging at Europython around 2010) and I had followed closely the then-failed distutils2 effort. And I still don't know what's the "right and easy way to do it".

Re: Current State of Python Packaging

#39

Is pipenv not recommended any longer ?

It was NEVER recommended by any Python organization or official person, it was just Kenneth's usual bullshit marketing.

In the link below it says, “Pipenv is recommended for collaborative projects”

https://packaging.python.org/tutorials/managing-dependencies...

Re: Current State of Python Packaging

#40

Yet another state of python packaging that: - skip the explanation on the py command on windows, the version suffixes on unix, -m and why you need to install pip on linux but not on the other OSes. - doen't address the various sys path issues of pip and poetry. Because at some point you need to install peotry. - ignore the existence of the excellent and simple setup.cfg. - ignore the consequences of using poetry on I…

Hi, I am the author of the post. Thank you for the ideas. The post is meant to be "dynamic" and I will integrate your ideas in it. I just woke up so in an hour or so I will update it.
Post reply on HN