4 ms·

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 loc

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 https://wiki.debian.org/Teams/RustPackaging/Policy

bombolo 4y ago
> 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 :)
- burntsushi 4y ago
  I haven't heard anyone complain about how Rust programs are packaged. Take your passive aggressive bullshit somewhere else.
  - sseagull 4y ago
    How Linux package managers handle these newer languages with their own package managers (including rust) is an ongoing pain point. Here’s an article from 2017 about it, and I don’t know if things have improved: https://lwn.net/Articles/712318/ https://lwn.net/Articles/712318/
    - burntsushi 4y ago
      I didn't say it wasn't a pain point or that there weren't challenges. I said I don't hear about people complain about how Rust programs are packaged. Not that the packaging of Rust programs (among others) itself doesn't present interesting challenges depending on the policies of a particular distro. Archlinux, for example, has far fewer problems than Debian because of differences in policy. The poster I was responding to was literally posting false information. I'm correcting it. This doesn't need to turn into a huge long sprawling discussion about packaging Rust programs. The main point that I was making is that lock files do not prevent Rust programs from being packaged. bombolo then went off on their own little tangents spouting nonsense without bothering to acknowledge their mistake.
      - bombolo 4y ago
        I contribute to packaging. But thanks for teaching me about something I know already. Now try to get something using an obsolete version of some python module into Fedora or Debian and let me know how it goes… It would not be accepted as it is. It'd be patched to work with a current one or just rejected.
        burntsushi 4y ago
        I never said a single word about Python. Whether you contribute to packaging or not has nothing to do with whether you're posting false information. If anything, it makes what you've said worse. You should know better. Just stop spreading misinformation. And the courteous thing to do is to acknowledge an error when it's pointed out instead of doubling down and redirecting as if no error was made.
        bombolo 4y ago
        The article is about python, the thread is about pinning dependencies in python.
        burntsushi 4y ago
        > Using lock files is a good way to make sure your software never ends up in a distribution and in the hands of users. > And how much rust software is packaged in distributions? Almost none. > They haven't figured out the procedures You're clearly talking about Rust in the second two comments. Your original comment was just a general pronouncement about lock files. You could perhaps be given the benefit of the doubt that you were only thinking about Python, but someone else interpreted your comment broadly to apply to any language with lock files. If you really only meant it to be specific Python, one would reasonably expect you to say, "Oh, sorry, I was only talking about Python. Not Rust. Their situation might be different." But no. You doubled down and started spouting nonsense. And you continue to do so! > Where dependency pinning is the norm, there is a culture of breaking API compatibility. Rust does not have this problem. It is the norm to use lock files for Rust programs, but there is no culture of "breaking API compatibility" without appropriate signaling via semver. This entire exchange is a classic example of Brandolini's law: https://en.wikipedia.org/wiki/Brandolini%27s_law https://en.wikipedia.org/wiki/Brandolini%27s_law It's easy for you to go off and spout bullshit. You've even been corrected by someone else who maintains distro packages. But it's a lot harder to correct it. You wriggle and squirm and rationalize and deflect.

bombolo 4y ago

> 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 :)

burntsushi 4y ago
I haven't heard anyone complain about how Rust programs are packaged. Take your passive aggressive bullshit somewhere else.
- sseagull 4y ago
  How Linux package managers handle these newer languages with their own package managers (including rust) is an ongoing pain point. Here’s an article from 2017 about it, and I don’t know if things have improved: https://lwn.net/Articles/712318/ https://lwn.net/Articles/712318/
  - burntsushi 4y ago
    I didn't say it wasn't a pain point or that there weren't challenges. I said I don't hear about people complain about how Rust programs are packaged. Not that the packaging of Rust programs (among others) itself doesn't present interesting challenges depending on the policies of a particular distro. Archlinux, for example, has far fewer problems than Debian because of differences in policy. The poster I was responding to was literally posting false information. I'm correcting it. This doesn't need to turn into a huge long sprawling discussion about packaging Rust programs. The main point that I was making is that lock files do not prevent Rust programs from being packaged. bombolo then went off on their own little tangents spouting nonsense without bothering to acknowledge their mistake.
    - bombolo 4y ago
      I contribute to packaging. But thanks for teaching me about something I know already. Now try to get something using an obsolete version of some python module into Fedora or Debian and let me know how it goes… It would not be accepted as it is. It'd be patched to work with a current one or just rejected.
      - burntsushi 4y ago
        I never said a single word about Python. Whether you contribute to packaging or not has nothing to do with whether you're posting false information. If anything, it makes what you've said worse. You should know better. Just stop spreading misinformation. And the courteous thing to do is to acknowledge an error when it's pointed out instead of doubling down and redirecting as if no error was made.
        bombolo 4y ago
        The article is about python, the thread is about pinning dependencies in python.
        burntsushi 4y ago
        > Using lock files is a good way to make sure your software never ends up in a distribution and in the hands of users. > And how much rust software is packaged in distributions? Almost none. > They haven't figured out the procedures You're clearly talking about Rust in the second two comments. Your original comment was just a general pronouncement about lock files. You could perhaps be given the benefit of the doubt that you were only thinking about Python, but someone else interpreted your comment broadly to apply to any language with lock files. If you really only meant it to be specific Python, one would reasonably expect you to say, "Oh, sorry, I was only talking about Python. Not Rust. Their situation might be different." But no. You doubled down and started spouting nonsense. And you continue to do so! > Where dependency pinning is the norm, there is a culture of breaking API compatibility. Rust does not have this problem. It is the norm to use lock files for Rust programs, but there is no culture of "breaking API compatibility" without appropriate signaling via semver. This entire exchange is a classic example of Brandolini's law: https://en.wikipedia.org/wiki/Brandolini%27s_law https://en.wikipedia.org/wiki/Brandolini%27s_law It's easy for you to go off and spout bullshit. You've even been corrected by someone else who maintains distro packages. But it's a lot harder to correct it. You wriggle and squirm and rationalize and deflect.