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

241–250 of 325 posts

Re: If this project is dead, just tell us

#241

Post by Barrin92 »

roelschroeven wrote: post #158
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.

Take SpeedCrunch for example: the current release (0.12) dates from 2015 AFAICS, and works very well for the most part. There's a bug in that release though: it thinks 0^1 is NaN. That bug was fixed in or before 2018 ( https://bitbucket.org/heldercorreia/speedcrunch/issues/836/0... ), but there has not been a release since. There have been a number of commits this year, but not a lot. Is the project dead or not? I ho…

not sure about the project but in a case like that the project management appears to be dead for sure, because releases should not trail vital bug fixes like that. Same for pipenv.

Re: If this project is dead, just tell us

#242

Post by traderjane »

bluGill wrote: post #186
sequoia wrote: post #131

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 actually think that accepting contributions productively is almost a full-time position and will turn you from programmer to manager.

Re: If this project is dead, just tell us

#243

Post by infecto »

chenning wrote: post #231
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.…

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…

I can of see a difference though. I am not condoning some of the ways I have seen Linus handle threads but it at least always seemed that there was a valid reason at the root. Maybe it was not communicated well but there did seem to be a reason. In the case of Pipenv, there were broken workflows that would have made this tool unusable for a large portion of the community and the response was just go pound sand? That specific case has been resolved since then but I dropped using it after that thread came up.

Re: If this project is dead, just tell us

#244

Post by chipotle_coyote »

peterwwillis wrote: post #165
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.

Similarly, Slackware Linux's last stable release was 14.2, in June, 2016, but their -current release tree was last updated.... yesterday. Now, I could be super huffy that they haven't released in years, but this is open source software that I'm not paying for. Moreover, I have the power to choose multiple alternatives. I can run the -current release. I can make my own "pseudo-release" by just forking here and calling…

I mean, you're right on all points, yet I confess I would be a lot more willing to give Slackware a try again if it would return to having a more-or-less annual official release, like it managed from its start in 1993 up through 2013. (Mast years prior to 2000 it had more than one release a year!)

There are things I (dimly) remember genuinely liking about Slackware in terms of its philosophy, but as near as I can tell the official installation method is "install the most recent ISO, then update from there," and when the most recent ISO is three and a half years old, that's not a great look. We've now gone the longest length in Slackware's history without even a point release.

I wouldn't demand Patrick make a new release, but I don't think it's wildly unreasonable to expect one by now. Bringing it back to the original article, I think the same can be said of pipenv.

Re: If this project is dead, just tell us

#245

Post by mook »

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/

By having the subdomain, they're endorsed (possibly transitively) by whoever runs python.org. If they want to _not_ endorse whatever PyPA is doing, they need to not supply the subdomain.

Re: If this project is dead, just tell us

#246

Post by MadWombat »

gwd wrote: post #57
rthomas6 wrote: post #31

Earlier quoted context omitted.

C/C++.

C/C++'s package management story is "defer it to distributions". Personally I much prefer `apt-get install libfoo-dev` to 1) each language inventing its own incompatible system, and 2) each developer self-publishing, so there's little to no safety or accountability when adding a new dependency.

> Personally I much prefer `apt-get install libfoo-dev`

So, what do you do when different projects need different versions of libfoo? Right, you download and build it locally inside the project tree and fiddle with makefiles to link to the local version rather than the one installed by apt-get. So basically you do your own dependency management. Good luck with that.

Re: If this project is dead, just tell us

#247

Post by luhn »

marcus_holmes wrote: post #238
chenning wrote: post #231

Earlier quoted context omitted.

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?

Not a dream. https://lkml.org/lkml/2018/9/16/167

Re: If this project is dead, just tell us

#249

Post by guggle »

icebraining wrote: post #179
guggle wrote: post #132

Earlier quoted context omitted.

If I had such need, I guess I could have two versions of the requirements.txt: - One with direct dependencies (versions pinned) - One with direct dependencies + subdependencies (pip freeze output) Am I being too naive ? (obviously yes if such tool as pipenv exists, but I'm trying to figure why people need *.lock files).

> One with direct dependencies + subdependencies (pip freeze output) That's a lock file...

Ok ! That's what I'd do then.

Re: If this project is dead, just tell us

#250

Post by guggle »

oblio wrote: post #174
guggle wrote: post #132

Earlier quoted context omitted.

If I had such need, I guess I could have two versions of the requirements.txt: - One with direct dependencies (versions pinned) - One with direct dependencies + subdependencies (pip freeze output) Am I being too naive ? (obviously yes if such tool as pipenv exists, but I'm trying to figure why people need *.lock files).

Are you only working on small projects? For reference, if your project is under 100k lines of code, it's small.

By your arbitrary metric, I work on both small and big projects. Not sure how the loc metric relates to the matter though.
Post reply on HN