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

291–300 of 325 posts

Re: If this project is dead, just tell us

#291

Post by Ar-Curunir »

YPCrumble wrote: post #87
sidmitra wrote: post #10

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…

I understand the value of a locking mechanism in the JS ecosystem because 1/ many packages depend on an intricate web of other packages that overlap, 2/ many packages use semver ranges, and 3/ you don't want two versions of the same package running on a user's browser, due to conflicts and increased size. I can't think of many Python packages that have the same issues, and Python code isn't sent to and running on a u…

I mean, Rust uses the same locking mechanism to great success. I've never seen a breaking change from upgrading a Rust dependency that preserves semver (which is 99% of them)

Re: If this project is dead, just tell us

#292

Post by gwd »

MadWombat wrote: post #246
gwd wrote: post #57

Earlier quoted context omitted.

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.

> So, what do you do when different projects need different versions of libfoo?

Well typically other people's projects I would normally rely on the distro to compile other people's projects as well; and then the distro maintainers would sort that out. That may include making a patch to allow older projects to use newer versions of a library; or if the library maintainer made breaking changes, it might mean maintaining multiple versions of the library.

Obviously if I myself need a newer version than the distro has, I may need to work around it somehow: I might have to build my own newer package, or poke the distro into updating their version of the library.

I mean, honestly, I don't build a huge number of external projects (for the reason listed above), and so I've never really run into the issue you describe. It seems to me that the "language-specific package" thing is either a side-effect of wanting basically the same dev environment in Windows and MacOS as on Linux, or of people just not being familiar with distributions and seeing their value.

Re: If this project is dead, just tell us

#293

Post by tsukurimashou »

theamk wrote: post #190
tsukurimashou wrote: post #103

Earlier quoted context omitted.

I wouldn't feel a thing, I would release the patch on my own fork and people would be free to merge my patch to their own fork or use mine as a base. It requires more work sure, but how would you solve that problem? People have their life, they can work hard on some project then drop it and never touch it again. You cannot force people willingly giving their time away for other people to do it all their life.

Do you think that a trivial, 4-line commit to README saying "this project is no longer maintained, look elsewhere" is too much to ask? I agree that you cannot force people to give their time away, and anyone can, and should be able to, stop maintaining any project they have. But putting "I am done" notice will likely take under 30 minutes, and will help a lot of people. It's a good idea to do it just out of respect t…

project maintainers are not your bitch, a lot of things can happen that could make them not add that line

Re: If this project is dead, just tell us

#294

Post by ben509 »

rolandog wrote: post #273
jlv2 wrote: post #267

Earlier quoted context omitted.

Not dead yet .

Technically, that applies to everyone of us, and every product---or service---we use...

Technically, there is an infintesimal chance that entropy spontaneously reverses permanently and that nothing ever dies.

Re: If this project is dead, just tell us

#295

Post by mixmastamyk »

CivBase wrote: post #182

I finally tried out pipenv a few months ago but I ran into a huge showstopper: pipenv does not allow you to target multiple versions of Python. I've seen sever pull requests requesting this feature but the author has officially stated that he does not plan to support it. My company still primarily uses Python 2, but I've been trying to push them towards 3. I need to support both in the mean time and that simply isn't…

It does support pyenv, does that not work for you?

Re: If this project is dead, just tell us

#296

Post by manigandham »

levosmetalo wrote: post #161
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.

Those 669 commits without a single release are pretty useless to the normal users. What would be the difference between 0 commits without a release and 669 commits without a release?

Well for one thing it means the project isn't dead, whether or not the release is ready.

Re: If this project is dead, just tell us

#297

Post by ejboy »

slantyyz wrote: post #219
the_duke wrote: post #135

Earlier quoted context omitted.

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…

> There are Java packages that haven't seen a commit in years and are still perfect for a task. My favorite is Scriptella ( http://scriptella.org/download.html ) which recently just got its first update in around 7 years. For what it does, it just worked, and for many uses cases, updates were never an issue.

Author of Scriptella here. Thank you for mentioning it! The product was neglected for many years, but I never was ready to finally press the kill switch. Hoping that one day I will have more time to work on it...

I cannot promise active feature development, but at least keep it compatible with recent JDK versions. Let me know if you have any feature requests on https://groups.google.com/forum/#!forum/scriptella or https://github.com/scriptella/scriptella-etl

Re: If this project is dead, just tell us

#298

Post by specialist »

Roles in a project should auto expire. Just like DHCP leases, or certificates, or elected offices, or...

Alternately, wire up an instance of The Button for each project. If a project's instance ever hits zero, someone else can adopt the project.

https://en.wikipedia.org/wiki/The_Button_(Reddit)

Re: If this project is dead, just tell us

#299

Post by teddyh »

MadWombat wrote: post #289
teddyh wrote: post #283

Earlier quoted context omitted.

> I should strive to never upgrade anything unless I absolutely must. It seems that the choice is whether to live on the slightly-bleeding edge (as determined by “stable” releases, etc), or to live on the edge of end-of-life, always scrambling to rewrite things when the latest dependency library is being officially obsoleted. I advocate doing the former, while you seem to prefer the latter. The problems with the form…

> but I think this is confusing something painful with something useful There is software out there that absolutely cannot break. Like "if this breaks, people will die". Medical software, power plant software, air traffic control software, these are obvious examples, but even trading and finance software falls into this category, if some hedge fund somewhere goes bankrupt because of a software bug real people suffer.…

> I am not working on anything like this. I work on a lighting automation system. If I fuck up my release, nobody is going to die (well, most likely, there are some scenarios), but if I fuck up sufficiently, a lot of people will be incredibly annoyed. So I have every version of every dependency frozen. All the way down the dependency tree.

Most people’s systems are not that special that they absolutely need to do this, but it feeds one’s ego to imagine that it is. And, as I said, it feels more painful, but it’s actually easier to do this – i.e. being a hardass about new versions – than to do the legitimately hard job of integrating software and having good test coverage. It feeds the ego and feels useful and hard, but it’s actually easy; it’s no wonder it’s so very, very easy to fall into this trap. And once you’ve fallen in by lagging behind in this way, it’s even harder to climb out of it, since that would mean upgrading everything even faster to catch up. If you’re mostly up to date, you can afford to allow a single dependency to lag behind for a while to avoid some specific problem. But if you’re using all old unsupported stuff and there’s a critical security bug with no patch for your version, since the design was inherently buggy, you’re utterly hosed. You have no safety margin.

Re: If this project is dead, just tell us

#300

Post by nitrogen »

cogman10 wrote: post #268
Reedx wrote: post #265

Earlier quoted context omitted.

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…

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

I disagree with this; it depends on the size of the dependency, plus the risk of a problem with the dependency vs the risk of making a mistake vs the risk of code drift when the same 10-min thing gets written a dozen different ways across an org.

Post reply on HN