Live data from Hacker News

If this project is dead, just tell us

github.com

231–240 of 325 posts

Re: If this project is dead, just tell us

#231

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.…

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 despise my decisions."

Re: If this project is dead, just tell us

#232

Earlier 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 hasn't been removed, because PyPA disagree [0].

> It's an official project of PyPA still, it's just not being pushed as the "be-all-end-all" option.

[0] https://github.com/pypa/packaging.python.org/issues/589

Re: If this project is dead, just tell us

#233

Earlier 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.

There are over 500 commits merged to master since the last release. The community is actively contributing but these changes don't get to the end user because the maintainers are not releasing them.

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

#235

Earlier 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.

Replace the word fan with supporter, which is more in line what what I was thinking, and is certainly needed in programming.

Re: If this project is dead, just tell us

#236

Earlier 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 love DepHell. I migrated some work repos from Pipenv (and plain ol' pip) to Poetry. However, we didn't want to have a flag day where we updated our build tooling to be 100% Poetry, so I made a Makefile target that builds requirements.txt and setup.py from pyproject.toml. Now developers can work with pleasant tooling, but the build system can use the old stuff it already knows.

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

#237
post #39

Earlier 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.

Whilst you might have to define "in the standard library", pip is added in PEP 453 [0] (accepted in 2013), in a similar capacity 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.

[0] https://www.python.org/dev/peps/pep-0453/

Re: If this project is dead, just tell us

#238

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.…

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…

Didn't Linus decide that he'd not been doing this well, and needed to change the way he managed conflict, though? Or did I dream that?

Re: If this project is dead, just tell us

#239

This "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…

I’m in a similar situation, maintaining a project that’s used widely enough it should probably have a continuity plan, but not enough that it’s developed a robust community of other contributors who could step in.

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

#240
post #180

I’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...

HN absorbed the trailing greater-than sign into your URL.

https://www.vincentprouillet.com/blog/overview-package-manag...

Post reply on HN