[bombolo]

> Any team of developers who aren't using the exact same environment are going to run into conflicts.

You've never done any open source development I guess?

Do you think all the kernel developers run the same distribution, the same IDE, the same compiler version? LOL.

Same applies for most open source projects.

[dang]

Would you please stop breaking the site guidelines? You've been doing it repeatedly, unfortunately. We want thoughtful, curious conversation here—not flamebait, unsubstantive comments, and swipes.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

[MrJohz]

A lot of modern open source projects include a lock file or some other mechanism that ensures that all contributors use the same versions of certain key tools. Obviously there are still going to be some differences in the environment, but for things like formatting, linting, etc, it's generally fairly easy to lock down a specific version.

In Python, the easiest way to achieve this is using Poetry, which creates a lock file so that all developers are using a consistent set of versions. In other languages, this is generally the default configuration of the standard package manager.

[bombolo]

Using lock files is a good way to make sure your software never ends up in a distribution and in the hands of users.

[MrJohz]

The popular Rust tool "ripgrep" uses a lock file for development (you can see it in the GitHub repo), and yet is in the official repositories for homebrew, various Windows package managers, Arch, Gentoo, Fedora, some versions of openSUSE, Guix, recent versions of Debian (and therefore Ubuntu), FreeBSD, OpenBSD, NetBSD, and Haiku.

With all due respect, I don't think you're correct.

[bombolo]

And how much rust software is packaged in distributions? Almost none. They haven't figured out the procedures, because distributions really really don't want pinned stuff around.

Homebrew, windows, arch all have very very relaxed processes to enter. There is no QA, you can just do whatever you want. I mean more like Fedora and Debian.

[burntsushi]

Bottom line is that the lock file in ripgrep's repo hasn't prevented it from being packaged. And I haven't heard of any distro maintainer complain about any lock file in any Rust program ever. So you're just plain empirically wrong about lock files preventing Rust programs from being packaged.

You've now moved on to talking about something else, which is "how much Rust software is packaged." Well, apparently enough that Debian has Rust packaging policy[1]. I'll give you one guess at what isn't mentioned in that policy. Give up? Lock files!

[1]: https://wiki.debian.org/Teams/RustPackaging/Policy

[bombolo]

> So you're just plain empirically wrong about lock files preventing Rust programs from being packaged.

My mistake, seems rust packagers gave up on decent packaging. It isn't so for the python policy, I can assure you :)

[dontlaugh]

The distros will eventually stop this dangerous practice of mixing and matching versions for all dependencies. It can only work for a small set of system components, which is what every other OS does.

[bombolo]

It's more dangerous to let people pin dependencies and have vulnerable libraries in use forever.

[throwawaaarrgh]

Distros can keep their own lock file that is based on their own release branch's versions. If it doesn't build, the pkg maintainer will either file a bug report or make a patch, or neither.

Source: I maintain distro packages.

[bombolo]

But something building doesn't mean that it will work.

There can be changes that are different than function signature changes.

Where dependency pinning is the norm, there is a culture of breaking API compatibility. And you might not have a compiler error to inform you that the API has changed. Sometimes all you have is a commit message.