Chris Warrick

Here's some sources. This bug in 2017 is characteristic "Pipenv Halloween easter egg" [0]. Pipenv has caused lots of unneeded drama in the Python community[1] - just search for past Pipenv posts.

Most of the criticism comes from software developers, and I suspect Pipenv fans are hobbyists (like fuck me for choosing Python in production, right?) I doubt Go's tooling accepts this strange behavior from the maintainers[2]. Kenneth Rietz is NOT a core Python developer.

So for my opinion, we have Pipenv instead of Requests support for async/futures, HTTP2.0, Websockets, or better encoding. But the documentation gets updates I see: "Requests is the only Non-GMO... organic, grass-fed HTTP/1.1 requests"[3]. This emojifuck for humans has no drive, so Go has better HTTP packages now.

Python's packaging has gotten political. I hate politics. I won't help new programmers with Pipenv, and I don't care if that's good or bad. At least Poetry _respects_ PEPs with it's well-defined specification. But I'm not gonna fight a losing battle. Maybe Pipenv gets ironed out one day. Hell, maybe Java replaces Maven. But I grow weary of immature repo maintainers. I just need working code; yet I feel this answers to nobody.

[0] https://github.com/pypa/pipenv/issues/786

[1] https://chriswarrick.com/blog/2018/07/17/pipenv-promises-a-lot-delivers-very-little/

[2] https://github.com/pypa/pipenv/commit/fe78628903948013e8687d1a3be9fd4da2b6bd3d

[3] http://docs.python-requests.org/en/master/

> There's nothing wrong with CSV as it is for basic data transfer.

I disagree. CSV is horribly underspecified and many parsers have conflicting ideas on how things should work. I've hit areas where, for example, an API was generating a CSV that another API could read, but NOT if it was opened and then re-saved by Excel first (just re-saving, not editing), because Excel was making some trivial change in the format that the consuming parser couldn't handle. Then there's issues with encoding, localisation, and escaping (see, eg, https://chriswarrick.com/blog/2017/04/07/csv-is-not-a-standard/ although that's just scratching the surface).

That being said, this proposal seems worse in every way that existing CSVs, but I don't think the issue is "there's a well specified CSV standard with tons of parsers that won't change to support this new one", it's more that there is no standard, all the parsers are incompatible, and no meaningful improvements are possible. :(

There's also scikit-build (https://scikit-build.readthedocs.io/en/latest/), a wrapper around CMake, like how meson-python is a wrapper around meson, and enscons (https://github.com/dholth/enscons, which is by the original wheel creator), which is a wrapper around SCons (I'm not sure how much maintenance it gets though).

It's interesting that the original post (https://chriswarrick.com/blog/2023/01/15/how-to-improve-python-packaging/) complained about there being too many options (whilst missing the "scientific python" and rust backends, and including wheel (which is part of setuptools now) and venv (which is primarily a library)), when much of the original push to standardise packaging came from the scientific python community (see e.g. https://pypackaging-native.github.io/), and the need to get away from a distutils/setuptools monoculture (given previous attempts at improving the situation e.g. bento).

Regarding not being able to work outside the project root[0]: This is actually one of the things that I love about pipenv! Anaconda, for instance, has environments that are not tied to a directory and are referred to by name (rather than by a directory path) and I've found this to be an absolute nightmare and extremely cumbersome! Not everyone has 10 projects that can share the same environment. (Besides, I would argue they never should.) I, for instance, have 10 projects that all require a slightly different environment and it's much easier to type a generic `pipenv shell` on the command line no matter what project I'm in, rather than trying to remember the Conda environment's name time and again. (Besides, it can be easily automated using .bashrc.)

[0]: https://chriswarrick.com/blog/2018/07/17/pipenv-promises-a-lot-delivers-very-little/#working-outside-of-the-project-root

Pipenv tries to do so much (e.g. a pipenv command involve poking around procfs to detect shell via shellingham to display colors), used to introduce breaking changes between releases (before they switched the scheme to CalVer), and takes a really long time between each releases (longer for bugs to get fixed).

Most people that switched from Pipenv to Poetry were probably done so during the end of 2018 throughout 2019, of which Pipenv has no releases at all[1] (non-alpha/beta version were only released in November 2018 then May 2020).

There were a rant from few years ago[2][3] regarding other issues (performance, etc.).

[1]: https://news.ycombinator.com/item?id=21781421

[2]: https://chriswarrick.com/blog/2018/07/17/pipenv-promises-a-lot-delivers-very-little/

[3]: https://news.ycombinator.com/item?id=18612590

Interesting reading, I share some of the points in the post, however, one more dependency manager?

Mostly I've used plain `python -m venv venv` and it always worked well. A downside - you need to add a few bash scripts to automate typical workflow for your teammates.

Pipenv sounds great but there are some pitfalls as well.
I've been going through this post recently and got a bit upset about Pipenv:
https://chriswarrick.com/blog/2018/07/17/pipenv-promises-a-lot-delivers-very-little/

Another point is that it does not work well with PyCharm and does not allow to put all dependencies into the project folder as I used to do with venv. (just like to keep everything in one folder to clean up it easily)

Are there any better practices to make life easier?