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

311–320 of 325 posts

Re: If this project is dead, just tell us

#311

Post by rubans »

strunz wrote: post #210
xenator wrote: post #105

Pipenv is very controversial project who lost its reputation. Many times I have issues that was making my everyday life very uncomfortable. And of course I saw issues on GitHub with other people who also have the same problems. And then in the middle of the very constructive conversation somebody from the maintainers team or initial creator of the project jumping to the thread and very aggressively close it or saying…

Can you link to one of these times a maintainer said something like that?

Here's an archived issue thread from Open Cart when the project owner gets unreasonably aggressive https://gist.github.com/T-Spoon/5a7cca7ea11c45b63c139da009c1...

Re: If this project is dead, just tell us

#312

Post by rubans »

strunz wrote: post #210
xenator wrote: post #105

Pipenv is very controversial project who lost its reputation. Many times I have issues that was making my everyday life very uncomfortable. And of course I saw issues on GitHub with other people who also have the same problems. And then in the middle of the very constructive conversation somebody from the maintainers team or initial creator of the project jumping to the thread and very aggressively close it or saying…

Can you link to one of these times a maintainer said something like that?

https://gist.github.com/T-Spoon/5a7cca7ea11c45b63c139da009c1...

Re: If this project is dead, just tell us

#313

Post by josteink »

myalphabet wrote: post #172
josteink wrote: post #169

Earlier quoted context omitted.

But all your examples are simple and reliable tools with a minimum of intricacy. My criticism isn’t about having a package-management story. It’s about having a terrible and complex one.

Your original comment was responding 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.” and saying that this is overly complicated. Yet every single one of the listed languages has package management tools that do all of these things. If you think any of the listed examples have “simple” p…

Python only has venvs because it needs venvs.

For most other language-provided package-managers the software project you’re working on is the env, so you don’t need to construct or manage a venv at all.

So my point still stands.

Re: If this project is dead, just tell us

#314

Post by dbsmith83 »

linuxftw wrote: post #121
Scarblac wrote: post #69

Earlier quoted context omitted.

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.

pip freeze gets everything installed. Yes, that 'freezes' everything installed... but that's the point. If you want to update a direct dependency, you just do pip install -u . Any indirect dependencies are updated, and you freeze again. Sometimes direct-dependency-a and direct-dependency-b have a conflict on which version of indirect-dependency-y you need. This is what we call doing 'actual work.'

^This. I don't understand everyone in this thread complaining that it's hard to update a direct dependency. You literally just pip install it and "pip freeze > requirements.txt" again.

In my experience, the issues come around when you try to build envs cross-platform. There are a lot of dependencies that have missing versions or bugs for certain platforms. This is not a pip/venv problem though--it is more of a python problem.

Re: If this project is dead, just tell us

#315

Post by slantyyz »

ejboy wrote: post #297
slantyyz wrote: post #219

Earlier quoted context omitted.

> 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 ht…

I think Scriptella is fantastic. It does one thing extremely well, and for me, that's all I can ask for.

Re: If this project is dead, just tell us

#316

Post by nitrogen »

nwallin wrote: post #304
nitrogen wrote: post #300

Earlier quoted context omitted.

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.

I think you are dramatically underestimating the cost of a dependency. The dependency may change in surprising ways in the future. The dependency may not change in expected ways in the future. (ie, now you're trapped in an old version of the language, or another one of your dependencies) The problematic part with reinventing the wheel or NIH is that you add a fixed cost of doing business to any given change. The prob…

I think you may be dramatically underestimating the cost of NIH and code bloat.

I'm talking about things developers think they can do in ten minutes but that they are at high risk of getting wrong: generating SQL, parsing JSON, handling dates, etc. These are all things that have well-established libraries in most sane languages (maybe NodeJS is not sane in this regard), where everything that you save yourself from by using the library is worth even a 40 hour review process.

Re: If this project is dead, just tell us

#317

Post by tus88 »

the_duke wrote: post #135
zubspace wrote: post #123

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…

How's this for a metric: number of stars divided by number of open issues.

Who cares if something has not commit for 7 years if almost noone uses it and it has no real issues?

On the other hand, you would hope a popular library with heaps of bugs and issues is receiving lots of maintenance.

Re: If this project is dead, just tell us

#318

Post by fulldecent2 »

Here's how you solve this problem. I do this on my own projects and with Chart.js which we resurrected from the brink of a "2.0 is coming... please wait" cliff.

1. Add a project scope to the README -- this gives you and volunteers grounds to close issues that are not relevant. 2. Send a personal email to your 3 top contributors -- ask if you can give them push access (even if they aren't recent contributors) at a minimum as an insurance policy. 3. Automate or at least specify your release process. You should be able to do this reliably, while drunk and high, and when you have 17 other projects needing your attention. Example: https://github.com/fulldecent/FDWaveformView/blob/master/CON...

I have been involved in a few "takeovers" to implement the above and keep great projects running. A little structure and human goes a long way. You don't need to fork and be the new dictator to keep something great moving.

Re: If this project is dead, just tell us

#319

Post by fulldecent2 »

the_duke wrote: post #135
zubspace wrote: post #123

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…

These are not great metrics. There are no great metrics.

The official JSON implementation is a good example. It is a mature project. It's used everywhere. If you leave an issue or submit a PR that fixes a typo, the maintainer will flat out delete your comment and tell you to buy his book to educate yourself.

Maybe this behavior is good or maybe it's bad. But maintainers are human and metrics are not going to cleanly pick up how well a project is maintained.

Re: If this project is dead, just tell us

#320

Post by manx »

I think for each project on Github it would make sense that the community can vote to have their own "official" community fork. PRs are then accepted by community approvals.

Changes can be merged back to the original repo. The maintainer could also declare the community fork to become the official project (and get its name).

This avoids lots of hassles with blaming the maintainer or organizing the community who want to help.

Post reply on HN