If this project is dead, just tell us • Hacker News Board

Re: If this project is dead, just tell us

#131

Post by sequoia » Fri, Dec 13, 2019, 3:03 PM UTC

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" I mean "we, the whole community, including maintainers and consumers of the project, took maintenance for granted or were not concerned about it." Anyone who installed the tool without reading the project's governance model and maintenance plan signed up for "whatever happens happens," the governance model of most small projects. I myself do this all the time, I'm not saying I'm better by any means. To participate in the JavaScript/Python/etc. ecosystem generally requires being OK with this.

To me this isn't a question of one project, it's a question of OSS project governance in general. Is there a succession plan? How do you know when more maintainers are needed? How do you promote someone from contributor to committer to releaser?

We went around adding CoCs to everything a few years ago, perhaps a similar effort could be made with governance plans? Like a boilerplate plan projects could use, hopefully leading to a new community norm of "if you are using a project with no governance plan, that's up to you, but don't say you weren't warned!"

Re: If this project is dead, just tell us

#132

Post by guggle » Fri, Dec 13, 2019, 3:03 PM UTC

Scarblac wrote: post #112

akvadrako wrote: post #80

Earlier quoted context omitted.

It’s easy to also get the versions of all sub dependencies and put them in requirements.txt

But then you're suddenly responsible for keeping track of your subdependencies and updating the versions of each that you want. That should be up to the dependencies. Also if you manage to drop a dependency, you don't have an easy way to remove the things from requirements.txt that are only there because they're a subdependency. Putting it all in one requirements.txt is just too simplistic.

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

Re: If this project is dead, just tell us

#133

Post by snypox » Fri, Dec 13, 2019, 3:04 PM UTC

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?

Well, I'd say it makes it so much smoother, almost 'not a pain' anymore.

Re: If this project is dead, just tell us

#134

Post by scrollaway » Fri, Dec 13, 2019, 3:04 PM UTC

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?

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.

Re: If this project is dead, just tell us

#135

Post by the_duke » Fri, Dec 13, 2019, 3:04 PM UTC

zubspace wrote: post #123

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.

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 or provide guidance on a PR.

If this happens quickly and with reasonable responses, projects are usually solid, assuming they have existed for a while and see decent usage.

Re: If this project is dead, just tell us

#136

Post by owl57 » Fri, Dec 13, 2019, 3:05 PM UTC

madeofpalk wrote: post #53

josteink wrote: post #24

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.

I thought NPM was everyone's favourite hated package manager/repository?

Yes, but for opposite reasons. You probably don't get left-pad in an ecosystem without one — and preferably only one —obvious way to publish and use it.

Re: If this project is dead, just tell us

#137

Post by totalperspectiv » Fri, Dec 13, 2019, 3:05 PM UTC

geekles wrote: post #25

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

Huge fan of poetry. I highly recommend people try it out. It feels like cargo, but for python.

Re: If this project is dead, just tell us

#138

Post by SmirkingRevenge » Fri, Dec 13, 2019, 3:05 PM UTC

Scarblac wrote: post #69

guggle wrote: post #56

Earlier quoted context omitted.

I don't get it either... nor do I understand why venv is considered difficult to use. "It automatically creates and manages a virtualenv for your projects, as well as adds/removes packages from your Pipfile as you install/uninstall packages." Well, thanks but automate "python -m venv myvenv" ? Add/remove packages from a "Pipfile" ? Do I have to specify dependencies somwhere else than requirements.txt ? Why ? There mu…

It's about dependencies of dependencies. Requirements.txt only lists versions of your project's requirements, but Pip actually automatically installs dependencies of those requirements too. And those versions aren't listed in your requirements.txt. https://realpython.com/pipenv-guide/#dependency-management-w... -- This page about Pipenv vs pip + virtualenv goes into more detail.

Giving a shout out to pip-tools here... it's a great, simple solution for pinning your requirements (including the deps of your deps), and keeping your venv's in sync.

Re: If this project is dead, just tell us

#139

Post by ausjke » Fri, Dec 13, 2019, 3:05 PM UTC

used to mainly/solely use pipenv, since it is in stale for quite a while now, I switched to the default venv, good enough for my use cases, and probably for 90% of other's user cases as well, I no longer feel pipenv is that important at all, get over with it, and move on.

    python3 -m venv myvenv
    source myvenv/bin/activate
    pip install -U pip
    pip install whatever
    
    deactivate

Re: If this project is dead, just tell us

#140

Post by totalperspectiv » Fri, Dec 13, 2019, 3:07 PM UTC

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?

I feel like it might, if it replaced pip and gets full endorsement from the python org. It's a fantastic project, but untill it has complete backing it's just a technical risk to include in a project.