Hacker News Reader

Hacker News

Comment by potetm | Hacker News Reader

Parent Full thread

potetm

The point isn't, "There are zero problems with maven. It solves all problems perfectly."

The point is, "You don't need lockfiles."

And that much is true.

(Miss you on twitter btw. Come back!)

View on HN

I think Maven's approach is functionally lock-files with worse ergonomics. You can only use the dependency from the libraries you use, but you're waiting for those libraries to update.

As an escape hatch, you end up doing a lot of exclusions and overrides, basically creating a lockfile smeared over your pom.

P.S. Sadly, I think enough people have left Twitter that it's never going to be what it was again.

Of course it's functionally lock files. They do the same thing!

There's a very strong argument that manually managing deps > auto updating, regardless of the ergonomics.

P.S. You're, right, but also it's where the greatest remnant remains. :(

I fear it says something unfortunate about our entire subculture if the greatest remnant remains at the Nazi bar. :(

(To be generous: it might be that we didn't build our own bar the moment someone who is at least Nazi-tolerant started sniffing around for the opportunity to purchas the deed to the bar. The big criticism might be "we, as a subculture, aren't punk-rock enough.")

If Twitter is a Nazi site then why do I have to block Laura Loomer & Ben Shapiro manually?

JFC, get off Twitter. It's a Nazi propaganda site and you are going to be affected by that even if you think you're somehow immune.

> P.S. Sadly, I think enough people have left Twitter that it's never going to be what it was again.

Majority of those people came back after a while. The alternatives get near-zero engagement, so it's just shouting into the wind. For the ones that left over political reasons, receiving near-zero engagement takes all the fun out of posting... so they're back.

I'd be willing to bet that 95% of my "followers" on Twitter are bots. So I get near-zero engagement, or engagement that is worth zero.

it is worth it to go through and block all bot followers. your engagement will likely improve afterwards.

You don't need package management by the same token. C is proof of that.

Having worked professionally in C, Java, Rust, Ruby, Perl, PHP I strongly prefer lock files. They make it so much nicer to manage dependencies.

"There is another tool that does exactly the job of a lockfile, but better."

"You can use make to ape the job of dependency managers"

wat?

I have worked with Maven and dependency management is a pain. Not much nicer than vendoting dependencies like you do for C. When I first was introduced to lock files that was amazing. It solved so many problems I had with vendored dependencies, CPAN and Maven.

Just because thousands of programmers manage to suffer through your bad system every day does not make it good.

Now you're moving the goalposts; I think lockfiles that are checked-in to version control are superior to Maven's "Let's YOLO it if your transitive dependencies conflict." Version ranges are more expressive than single-versions, and when you add lockfiles you get deterministic builds.

I don't understand how Maven's YOLO is different from NPM's range.

If you force a transitive dependency in Maven, then yes, some other library may get incompatible with it. But in NPM when people declare dependency as, say, ~1.2.3 the also don't know if they will be compatible with a future 1.2.4 version. They just _assume_ the next patch release won't break anything. Yes npm will try to find a version that satisfies all declarations, but library devs couldn't know the new version would be compatible because it wasn't published at that time.

And my point is that it's _exactly_ the same probability that the next patch version is incompatible in both Maven and NPM. That's why NPM users are not afraid to depend on ~x.x or even ^x.x, they basically YOLOing.

Yeah, npm people expect that semantic versioning will be abided by. Obviously, it will not work if a minor version bump introduces a breaking change. Obviously this is better than pinning the same one dependency in literally every package - imagine the churn and the amount of life lost to bumping dependencies in any given ecosystem if every package had to pin a specific version of a dependency.

Ultimately, these are imperfect solutions to practical problems, and I know that I much prefer the semantic versioning and lockfile approach to whatever the java people are into.

> I don't understand how Maven's YOLO is different from NPM's range.

The person who wrote the range selected a range that they deem likely to work.

I don't use NPM, but in Python it definitely happens that you see e.g.:

  foo >= 0.3.4, <= 0.5.6

Which can save a lot of headaches early on for packages that use ZeroVer[1]

1: https://0ver.org/

From my experience, this is a self-policing issue in the npm ecosystem. When major packages break semver, the maintainers take a ton of heat. When minor packages do it, they quickly fall out of the ecosystem entirely. It's not "YOLO"ing, but rather following the ecosystem conventions.

But anyway.. isn't that exactly the purpose of lock files? If you don't trust the semver range, it shouldn't matter because every `npm ci` results in the same package versions.

Maven builds are deterministic (so long as you don't have SNAPSHOT dependencies). The version resolution is insane but deterministic. You'll only break that determinism if you change the dependencies.

That's precisely because maven doesn't support version ranges. Maven artifacts are also immutable.

Maven also supports manual override when the insane resolution strategy fails that's the "dependencymanagement" section.

Lockfile builds are also deterministic. You only break that determinism if you change the lockfile.

I typically just add an <exclusion> for one of my top level dependency, so Maven picks from some other.

You can use version range with a maven plugin

https://maven.apache.org/enforcer/enforcer-rules/versionRang...

Reply on news.ycombinator.com