Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If this project is dead, just tell us

github.com

Post reply on HN
Print view View original

221–230 of 325 posts

Re: If this project is dead, just tell us

#221

Post by infecto »

shakna wrote: post #209
infecto wrote: post #203

I was pretty badly turned off by Kenneth Reitz and the way he handled conflict with Pipenv. I disliked how instead of listening to feed back or being constructive he just gave off a kind of fuck you attitude. There were real and critical issues with pipenv that he would not budge on and it truly felt like he was in the minority. I know, its his project he can do what he wants but in the context it did not make sense.…

> Use Pipenv to manage library dependencies when developing Python applications. See Managing Application Dependencies for more details on using pipenv. > Consider other tools such as pip when pipenv does not meet your use case. Is this [0] not an official endorsement? It certainly seems as much. [0] https://packaging.python.org/guides/tool-recommendations/

Oh wow new to me. Had not seen that one. Even more disappointing because the tool is far from primetime. Going back to the original. A few years back when I was using pipenv it kept the tagline that it was the future of python and endorsed fully but I am pretty sure that was a stretch or perhaps the maintainer was using his clout and his own recommendation.

Re: If this project is dead, just tell us

#222

Post by gonational »

tiborsaas wrote: post #117
mikkelam wrote: post #8

Pipenv has spawned so much controvery.. One big shitfest. Python packaging in general is such a messy ecosystem

Do you think Poetry solves this package management mess?

Poetry is the solution, IMHO.

I’m sure poetry has bugs and it could have other problems (not sure), but if you look into how it works, from a software design / philosophy perspective, it’s absolutely amazing. It might be worth waiting a bit longer before you use it in a large production project. Once Heroku adds native support to the Python buildpack, and some other mainstream avenues add support, Poetry usage will increase enough to create the necessary scrutiny that will bring it up to true production-grade quality.

When you add a package in Poetry it will add the latest version of that package’s dependencies that also satisfy all the other packages (and their dependencies’ dependencies).

If you remove a package, Poetry will remove any dependencies of that package (actually uninstall them, rather than just leaving junk behind like pipenv), and will reestablish the latest versions of any other dependencies who’s versions were held back by the package you just removed or any of its dependencies...

Also, when you add a package with Poetry it doesn’t need to completely lock and install everything from scratch; only what you have just added and whatever its dependencies dictate; nothing more.

Also, you can tell Poetry to list off all the versions of your packages and the latest versions available (in case you’re like me and you pin all of your top level packages, having to Google “pypi django”, “pypi requests”, etc., to see if there are any newer versionS worth upgrading to, is a pain in the ass.

Re: If this project is dead, just tell us

#223

Post by xkcd-sucks »

scrollaway wrote: post #134
tiborsaas wrote: post #117

Earlier quoted context omitted.

Do you think Poetry solves this package management mess?

To a point. Poetry still isn't fully in board with being a project manager, it focuses too much on packaging. For example it doesn't do project scripts like nom scripts.

It doesn't support shell scripts which kind of sucks, but could be reasonable if it is expected to run on windows as well as posix. This is the scripts section from one project I used Poetry in. It seems to be fine for most things, even though the focus on managing a python module for publication is a little bit annoying. Once or twice I've run into version resolution troubles, but generally it's stable and much more ergonomic+easier to explain than pip+venv. One can of course use `poetry run pip freeze` to generate the standard `requirements.txt` file

   [tool.poetry.scripts]
   # NB: Poetry won't run arbitrary callables, so these are wrapped in a python script.
   # Poetry needs the root dir to be a package (e.g. module `my_repo` must exist) in order to run scripts
   # So they are just shoved into a dummy "my_repo.py" instead of going in e.g. "scripts.py"
   # Adds Git hooks from `git_hooks` path (overwrites existing!)
   hookup = "my_repo:hookup"
   # Run formatter+linter, does not modify anything, errors if fail
   lint = "my_repo:lint"
   # runs `black` (formatter), modifies stuff
   format = "my_repo:format"
   # A list of files which failed linting. Most helpful with flake8 vim integration https://github.com/nvie/vim-flake8
   lintyfiles = "my_repo:lintyfiles"
   # unit tests
   utest = "my_repo:utest"
   # unit + integration tests in container
   citest = "my_repo:citest"
   cutest = "my_repo:cutest"

Re: If this project is dead, just tell us

#224

Post by jzl »

shakna wrote: post #209
infecto wrote: post #203

I was pretty badly turned off by Kenneth Reitz and the way he handled conflict with Pipenv. I disliked how instead of listening to feed back or being constructive he just gave off a kind of fuck you attitude. There were real and critical issues with pipenv that he would not budge on and it truly felt like he was in the minority. I know, its his project he can do what he wants but in the context it did not make sense.…

> Use Pipenv to manage library dependencies when developing Python applications. See Managing Application Dependencies for more details on using pipenv. > Consider other tools such as pip when pipenv does not meet your use case. Is this [0] not an official endorsement? It certainly seems as much. [0] https://packaging.python.org/guides/tool-recommendations/

Those pages are managed by the "PyPA" group, not technically python.org itself, although they were given a subdomain there. Start here and follow the links for more info: https://hynek.me/articles/python-app-deps-2018/

Re: If this project is dead, just tell us

#225

Post by jzl »

jarnagin wrote: post #205
noname120 wrote: post #154

Earlier quoted context omitted.

> The python packaging team was officially recommending it NO! This is a common misconception[1]. Edit: Correction it's not endorsed by the core Python team but it's recommended by the Python Packaging Authority in various places. See replies below for more info. [1] https://chriswarrick.com/blog/2018/07/17/pipenv-promises-a-l...

It’s officially recommended on packaging.python.org [1]. If that’s not enough to count as an official endorsement, what is? [1] https://packaging.python.org/guides/tool-recommendations/

Those pages are managed by the "PyPA" group, not technically python.org itself, although they were given a subdomain there. Start here and follow the links for more info: https://hynek.me/articles/python-app-deps-2018/

Re: If this project is dead, just tell us

#226

Post by domoritz »

noname120 wrote: post #213
shakna wrote: post #208

Earlier quoted context omitted.

However, over here [0] I see pipenv, but not those: > Use Pipenv to manage library dependencies when developing Python applications. See Managing Application Dependencies for more details on using pipenv. > Consider other tools such as pip when pipenv does not meet your use case. That recommendation is absolutely unambiguous. [0] https://packaging.python.org/guides/tool-recommendations/

Right, I stand corrected.

So if it isn't supposed to be officially endorsed, should someone file an issue at https://github.com/pypa/packaging.python.org/issues?

Re: If this project is dead, just tell us

#228

Post by jlengrand »

alecbenzer wrote: post #155
coleifer wrote: post #109

I see a lot of comments about "hey it's open-source, just fork". The reason people feel upset is because this project was shilled hard when it was released. The python packaging team was officially recommending it, stuff like that. There was some backlash because of legitimate usability concerns with the software, and what was perceived as the tacit blessing of a project solely due to the maintainer's having written…

> the maintainer's having written another popular project. Potentially relevant: https://vorpus.org/blog/why-im-not-collaborating-with-kennet...

Holy crap. I had never heard of anything like that regarding him

Re: If this project is dead, just tell us

#229

Post by kstrauser »

casion wrote: post #18

669 commits in the last year... and asking if the project is dead? I'm a bit confused here. Maybe the project is mismanaged, or there's some upstream issue with package distro, but it seems to be far from dead.

It's definitely tapered off, though: https://github.com/pypa/pipenv/graphs/commit-activity

There's no activity in December. There was one commit in November, and that removed a Fedora version number from the readme.

Re: If this project is dead, just tell us

#230

Post by shakna »

jzl wrote: post #224
shakna wrote: post #209

Earlier quoted context omitted.

> Use Pipenv to manage library dependencies when developing Python applications. See Managing Application Dependencies for more details on using pipenv. > Consider other tools such as pip when pipenv does not meet your use case. Is this [0] not an official endorsement? It certainly seems as much. [0] https://packaging.python.org/guides/tool-recommendations/

Those pages are managed by the "PyPA" group, not technically python.org itself, although they were given a subdomain there. Start here and follow the links for more info: https://hynek.me/articles/python-app-deps-2018/

I'm aware that the Python Packaging Authority is not the Python Software Foundation. But they are also the Packaging Authority.

The PSF may not have officially granted them some sort of status, but as PyPA maintain pip, setuptools and warehouse, they are in fact the authority when it comes to packaging, unless the PSF comes out with a statement saying they aren't.

Post reply on HN