Live data from Hacker News

If this project is dead, just tell us

github.com

141–150 of 325 posts

Re: If this project is dead, just tell us

#141

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…

That's the real issue here: prominent, established projects recommending other projects that are not remotely as well-established as the big projects, whereas such a recommendation may suggest that it is.

Big, high exposure projects should probably wait to recommend interesting new projects for actual use until they are sure that the management of that project is in reliable hands with enough backup to continue it if the original creator vanishes.

Re: If this project is dead, just tell us

#142

Earlier quoted context omitted.

> Python packaging in general is such a messy ecosystem Not just messy. It’s probably worst in class. I at least can’t come up with a single worse package-management story which I do know of. Edit: I’m talking about platforms with actual package-management which sucks, not platforms with the absence of package-management all together.

Well, C/C++ dependencies are also a hell to reliably setup on different platforms.

Have you tried Conan[1] by chance? I've only used it for small projects, but it was pretty nice.

https://conan.io/

Re: If this project is dead, just tell us

#143

Earlier quoted context omitted.

Determining if a project is alive or dead really is a problem. And this problem will grow from year to year. There are so many small and medium sized projects on Github, where you have no idea if they are maintained or not. Sometimes there are projects which are alive and kicking with multiple pull requests, maintainers promising changes or a major release and suddenly nothing. Sometimes smaller projects see no chang…

You said it yourself, this is a very hard problem. There are Java packages that haven't seen a commit in years and are still perfect for a task. There are npm packages that are 2 months old and terribly outdated and unmaintained. My personal favorite metric is "time to maintainer response": how long does it take for a maintainer to respond to issues or pull requests. Not necessarily to resolve them, but triage issues…

In this case, the code is still maintained and at least some pull requests are being processed (I haven't checked in detail). The only thing is that there hasn't been an official release for some time.

Re: If this project is dead, just tell us

#144

Earlier quoted context omitted.

They don't do the same thing. pipenv allows you to create, manage virtual environments(using venv) apart from managing requirements file(Pipfile) and an npm like locking mechanism, dependency graphs, dev dependencies and more. I prefer poetry though, since the consensus seems to be coming together on pyproject.toml rather than individual files like Pipfile. A lot of tools have already started supporting the toml file…

> pipenv allows you to create, manage virtual environments(using venv) apart from managing requirements file(Pipfile) and an npm like locking mechanism, dependency graphs, dev dependencies and more. Why on earth would anyone need all this to manage packages for their projects? Are there any other programming languages whose package-management comes close to this level of intricacy and complexity? “This project needs…

> Are there any other programming languages whose package-management comes close to this level of intricacy and complexity?

I think many do. Ruby, Node, Erlang/Elixir, Java, Go, Rust, dotnet, C... I’m having trouble thinking of a modern language that doesn’t have such package management mechanisms.

For many people doing anything more than writing one-off scripts, and especially for anyone who collaborates with others or shares their code, package management is so much more than just “this project needs package X”.

Re: If this project is dead, just tell us

#145
post #130

Earlier quoted context omitted.

Determining if a project is alive or dead really is a problem. And this problem will grow from year to year. There are so many small and medium sized projects on Github, where you have no idea if they are maintained or not. Sometimes there are projects which are alive and kicking with multiple pull requests, maintainers promising changes or a major release and suddenly nothing. Sometimes smaller projects see no chang…

> Maybe they could send a heartbeat to the maintainer and simply show the project as dead as soon as there is no response? If I could not automate response to that, I'd ignore it. My employer gets to make bullshit intrusions on my time like that, no way will I waste my life on make-work from Github.

Just fishing for a response wouldn't be very meaningful anyway. A far better metric would be the time it takes for a maintainer to respond to pull requests and other issues.

Re: If this project is dead, just tell us

#146
post #141

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…

That's the real issue here: prominent, established projects recommending other projects that are not remotely as well-established as the big projects, whereas such a recommendation may suggest that it is. Big, high exposure projects should probably wait to recommend interesting new projects for actual use until they are sure that the management of that project is in reliable hands with enough backup to continue it if…

I think that's the default for most high exposure projects. Unless, of course, both projects have the same author, and that author's primary concern is increasing their own exposure.

Re: If this project is dead, just tell us

#147
post #25

Meanwhile, Poetry just announced 1.0: https://python-poetry.org/blog/announcing-poetry-1-0-0.html

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.

There is also a bug that is keeping me from switching, and also the handling of that bug has not been great, otherwise I would do so in a heartbeat.

Re: If this project is dead, just tell us

#148
I am one of those grubby little "dark matter" developers. I fled Perl for Python over a decade ago. While I do love Python, one of the impediments (not the only, and perhaps not the largest) to my progress are the endless packaging issues. Among the larger attractions to Python is that there is supposedly one obvious way to do things and here there is not. Instead, I must make my selection largely based on opinions that have the same foreboding stink of those I associate with arguments over Linux distros: dashed-off dismissals starting with "just" and drive-by engagements with the topic.

As a result, I end up rarely going outside of the standard library. In a perverse way, being locked on an un-upgradable (due to Reasons) version of Python 2.7.5 for the foreseeable future has helped put that temptation a bit further away.

Yes, Packaging Is Hard. It is certainly beyond me. I will probably never need to package anything I wrote, much less distribute it, so many of my concerns are purely academic.

Rather than fussing over things like the walrus operator (really, c'mon), I would love to see those who steer Python buckle down on issues like this, solve them, and then relentlessly backport the solution further back than everyone thinks is reasonable.

Re: If this project is dead, just tell us

#149

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…

Broadly, "a project is being actively developed and makes releases reliably often" is a fairly tolerable maintenance plan.

It's only when that implicit contract breaks down that you get "is X dead?"

Re: If this project is dead, just tell us

#150
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.

From the post itself, the symptom is: people are committing, but releases are not being made.
Post reply on HN