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

261–270 of 325 posts

Re: If this project is dead, just tell us

#261

Post by isthisreality »

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…

The axios example is an interesting one, because there are tons of people saying they're willing to help, but how many of those people will actually contribute anything without guidance of any kind? When the current maintainers are too busy to even provide guidance, you need to be a special kind of developer to even have a chance of becoming a real maintainer, and those kinds of developers are few and far between.

Re: If this project is dead, just tell us

#262

Post by [deleted] »

at_a_remove wrote: post #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 t…

[deleted]

Re: If this project is dead, just tell us

#263

Post by sdenton4 »

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…

I think one could get most of the way there by having a bot that: a) Autobuilds the library based on its declared dependency stack. b) Runs a test suite, and reports back breakage.

Anything that sits broken more than (say) a month can safely be considered dead. Super-stable low-level code will continue passing their tests forever, and things dependent on specific API versioning in left_pad will be marked dead quickly...

Re: If this project is dead, just tell us

#264

Post by icebraining »

shdh wrote: post #193
icebraining wrote: post #189

Earlier quoted context omitted.

How do I declare packages needed for development/testing but not production? Yes, pipenv is mostly just a frontend to pip+venv, but that doesn't mean it isn't useful.

requirements-test.txt requirements-dev.txt pip install -r dev.txt

But then you can't "pip freeze" to get specific versions for production deployment.

Re: If this project is dead, just tell us

#265

Post by Reedx »

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…

Maintenance is something I've come to appreciate more and more every year.

It's so easy to install dependencies, but it comes with a large hidden cost and painful lessons down the line.

Re: If this project is dead, just tell us

#266

Post by doubleunplussed »

MadWombat wrote: post #259
teddyh wrote: post #254

Earlier quoted context omitted.

> So, what do you do when different projects need different versions of libfoo? That’s an untenable situation. The package which depends on the older version of libfoo is either dead, in which case you should stop using it, or it will soon be updated to use the newer version of libfoo, in which case you’ll have to wait for a newer release. This is what release management is.

> The package which depends on the older version of libfoo is either dead, in which case you should stop using it, or it will soon be updated to use the newer version of libfoo So you are suggesting that every time libfoo bumps its version I have to update the dependencies on all of my projects to use the latest, find and fix all the incompatibilities, test, release and deploy a new version? Seriously?

Yeah, I mean what's the alternative? Your code will bit rot if you don't keep up. You don't have a living software project if you don't do this.

You should read the release notes of the new version of your dependency, fix any obvious issues from that, see if your tests pass, and wait for bug reports to roll in for non-obvious things not caught by automated tests. Ideally you should do this before the new release of the dependency hits the repos of the distros most of your users use, so that it's only the enthusiasts that are hit by unexpected bugs.

Even if you could delay and batch the work together every several releases of a dependency, you're still doing the same amount of work, and it's usually simpler to keep up bit by bit than all at once.

One trick is to not use dependencies that have constant churn and frequent backward-incompatible changes, and to avoid using newly introduced features until it's clear they've stabilised. When you choose dependencies, you're choosing how much work you're signing up for, so choose wisely.

Of course you could go the alternate route and ship all dependencies bundled - but that is a way to ignore technical debt and accidentally end up with a dead project.

Also, your project should not demand a specific version of `libfoo`. If `libfoo` follows semver and a minor release breaks your project, that is a bug in `libfoo`. Deployments of production software should pin versions, but not your project itself.

Re: If this project is dead, just tell us

#268

Post by cogman10 »

Reedx wrote: post #265
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…

Maintenance is something I've come to appreciate more and more every year. It's so easy to install dependencies, but it comes with a large hidden cost and painful lessons down the line.

Yup. Further, I do a lot more research in the dependencies I bring in (if I can help it).

Does this thing also bring in 1000x sub dependencies? How much am I REALLY going to use this. What's the actual added value here.

I've seen people bring in libraries for simply the dumbest things. The worst offender I've seen is lombok brought in for a @Logger annotation on one class. That stopped our java 6->8 migration because the version of lombok they brought in was old and for highly used library (so upgrading wasn't simple).

If you can write the used functionality in 10 minutes, you should not bring it in as a dependency.

Re: If this project is dead, just tell us

#269

Post by nonbirithm »

toraobo wrote: post #162
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.

What would be an example of a good packaging ecosystem?

Probably cargo.

- It was built in to Rust from the beginning and officially sanctioned so fifteen different people don't have to build their own incomplete, buggy package managers.

- You can add plugins for things like automatically updating or adding dependencies.

- It handles projects and subprojects.

- All you have to do to install dependencies and run a project is "cargo run", reducing friction for getting into new projects.

- For the most part, it just works.

That said it isn't perfect, especially when needing custom build scripts, but it's good.

Re: If this project is dead, just tell us

#270

Post by teddyh »

doubleunplussed wrote: post #266
MadWombat wrote: post #259

Earlier quoted context omitted.

> The package which depends on the older version of libfoo is either dead, in which case you should stop using it, or it will soon be updated to use the newer version of libfoo So you are suggesting that every time libfoo bumps its version I have to update the dependencies on all of my projects to use the latest, find and fix all the incompatibilities, test, release and deploy a new version? Seriously?

Yeah, I mean what's the alternative? Your code will bit rot if you don't keep up. You don't have a living software project if you don't do this. You should read the release notes of the new version of your dependency, fix any obvious issues from that, see if your tests pass, and wait for bug reports to roll in for non-obvious things not caught by automated tests. Ideally you should do this before the new release of t…

Exactly. This is what we signed up for when we release software and commit to keeping it maintained. This is what we do.

If you instead just like writing software and throwing it over the wall/to the winds, you are an academian in an ivory tower, and have no connection to your users in the real world.

Post reply on HN