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.…
If this project is dead, just tell us
231–240 of 325 posts
Re: If this project is dead, just tell us
#232Earlier quoted context omitted.
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 ?
> It's an official project of PyPA still, it's just not being pushed as the "be-all-end-all" option.
Re: If this project is dead, just tell us
#233Earlier quoted context omitted.
It looks like 1.4k people have forked it. The question is, which fork do I use? The problem is not that the source is unable to be updated, the problem is how to you organize peoples' efforts under a trusted maintainer long term? How do I know which forking effort to trust? My understanding is that that's kind of the point of groups like the "Python Packaging Authority". So if they're not going to merge pull requests…
Alternatively, they could add one of those 1.4k people in to help if they seem to have produced working code for the project prior.
Bugs get reported and closed because they are fixed in master every day, wasting not only the end users time but also that of the people actively working on the project.
Re: If this project is dead, just tell us
#234Re: If this project is dead, just tell us
#235Earlier quoted context omitted.
Huge fan of poetry. I highly recommend people try it out. It feels like cargo, but for python.
fandom always leads to these hollow hypes that end in dead projects. we do not need that in programming.
Re: If this project is dead, just tell us
#236Earlier quoted context omitted.
The 1.0 release is a must for a working poetry environment. The people handling it are friendly and communicate over github and discord. However, it's not all roses. - VSCode supports poetry as a second class citizen - Documentation is there, but only in github issues - There is no migration path from pip and pipenv to poetry - I can't do releases via CI because of a poetry bug.
DepHell claims to be able to convert to and from pip, pipenv and poetry, so perhaps that could be used for migrating? https://dephell.org/docs/cmd-deps-convert.html
We're close to having everything migrated to Poetry. When that day comes, we can throw out all the compatibility stuff, update the build server, and be happy. Until that day, DepHell gives us an easy compatibility layer so that we don't have to do the migration all at once. It's awesome.
Re: If this project is dead, just tell us
#237Earlier quoted context omitted.
1. Because pipenv is easier to use. 2. Because it's not at all clear that pipenv is a third party library. It's made by the same group that makes pip, so it's confusing that pip would be considered a de-facto standard but not pipenv when it's made by the same group, and under the same project in Github.
pip is not yet in the standard library. as opposed to venv.
> However, to avoid recommending a tool that CPython does not provide, it is further proposed that the pip [18] package manager be made available by default when installing CPython 3.4 or later and when creating virtual environments using the standard library's venv module via the pyvenv command line utility.
Re: If this project is dead, just tell us
#238I 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.…
You know who else handled conflict in a way that wasn't always understood? Linus Torvalds. I think there's a theme here. Why is it that successful project maintainers sometimes lose their patience with the community? Remember when GvR left the Python community? I think one of his final public statements was, "Now that PEP 572 is done, I don’t ever want to have to fight so hard for a PEP and find that so many people d…
Re: If this project is dead, just tell us
#239This "project dead?" question pops up on many open source projects on github. One recent one: https://github.com/axios/axios/issues/1965 The issue seems to be similar to one that we programmers regularly encounter in our day jobs: failing to consider maintenance and/or make a plan for what happens to a project in one, two, or three years. I don't mean to say "the authors of this project failed to consider maintenance…
Can you suggest something a little more concrete? What should I add to my project so that if I die tomorrow the project can continue without me? I work on a small project. I didn't add a CoC when the big push came about because I concluded that it was if I say it is bad it is bad, otherwise it is good - that is no CoC and so there is no point. (I did consider asking some large project - KDE for example - to be arbitr…
Jazzband [0] seems meant to address exactly this: “a collaborative community to share the responsibility of maintaining Python-based projects.” And it looked promising, but it’s not entirely clear that the Jazzband project itself is all that active (only news status update is the launch announcement from 2015; last public Twitter activity was in 2017).
[0]: https://jazzband.co/
Re: If this project is dead, just tell us
#240I’ve heard good things about pip-tools: https://github.com/jazzband/pip-tools
I've tried pip-tools, pipenv and poetry and pip-tools has been the easiest to use by far. I wrote a small comparison last year: " rel="nofollow">https://www.vincentprouillet.com/blog/overview-package-manag...
https://www.vincentprouillet.com/blog/overview-package-manag...