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

Re: If this project is dead, just tell us

#321

Post by oblio » Mon, Dec 16, 2019, 10:01 AM UTC

zer00eyz wrote: post #251

oblio wrote: post #159

Earlier quoted context omitted.

Maven basically solved Java's dependency problems back in 2005.

Serious question: Isn't maven the reason that you can't really package Hadoop? It is my (high level) understanding that it is at the core of (or a big part of) why Hadoop is so hard to build on your own vs VM.

Hadoop is hard to package because build scripts are treated as second hand citizens for most projects. There's a high standard of code reviews for many projects, but for the build scripts it's "it works, merge it".

I've built quite big projects with Maven (>2 million LOC) without issues.

Re: If this project is dead, just tell us

#322

Post by jawilson2 » Mon, Dec 16, 2019, 2:06 PM UTC

reledi wrote: post #108

I’m really curious how places with heavy Python usage solve the dependency tree, packaging, distribution, release problems. I’m always lost about what the best practice is when I occasionally need to write Python. I just wish there was one way to do it all.

We have a lot of python code, along with C++ and Java, and it is an absolute nightmare dealing with python. If we include conda-forge as a channel, dependency resolves can take hours with the right/wrong combination of packages. We can't easily replicate environment across machines, and build times for our conda packages can take tens of minutes, just to copy a few py files around. We hate it, but our ecosystem is built on it (data science/ML/etc), so it is what we have to deal with. I always look at these threads with hope, but then envision the nightmare that would be involved in moving to poetry or some other system.

Re: If this project is dead, just tell us

#323

Post by cogman10 » Mon, Dec 16, 2019, 5:00 PM UTC

nitrogen wrote: post #316

nwallin wrote: post #304

Earlier quoted context omitted.

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…

None of the examples you've given are 10 minute problems. It isn't reasonable to think of them as such and so it is a straw man.

10 minute problems are things like

is-odd - https://www.npmjs.com/package/is-odd is-even - https://www.npmjs.com/package/is-even leftpad - https://www.npmjs.com/package/pad

Or bringing in large libraries to use single methods or functions from them. Such as

Bringing in gauva for max Bringing in apache commons for StringUtils.join.

I've seen both examples in my company's code base.

A library that does JSON parsing, date handling, etc is doing a lot more heavy lifting than "is-even".

Re: If this project is dead, just tell us

#324

Post by darepublic » Mon, Dec 16, 2019, 9:00 PM UTC

If we aren't going to make the delivery deadline, just tell us.

Re: If this project is dead, just tell us

#325

Post by [deleted] » Tue, Dec 17, 2019, 3:41 PM UTC

josteink wrote: post #313

myalphabet wrote: post #172

Earlier quoted context omitted.

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.

[deleted]