4 ms·

One of the perfect example of many toxic comment of entitled users...

deleted 6y ago
[deleted]
userbinator 6y ago
I bet you will be just as pissed off when others break your environment too... It's for this reason I've never liked the sprawling dependency-of-dependency mess that a lot of software projects seem to have.
- josephg 6y ago
  Yes; it’s particularly bad when you mix languages like this. I maintain the nodejs foundationdb libraries. Fdb doesn’t have a published wire protocol - bindings are expected to wrap a dynamically linked C library which contains the protocol implementation and net code. And that library is very “clever” - it leans heavily on codegen (via mono) and hand written asm to support a high performance actor model internally. The downstream effect is that FreeBSD support for database clients has only been added recently. There’s no native Apple M1 client support. There’s been issues with code signing in Java ... and so on. Generally you can only talk to a foundationdb server from an x86_64 client that runs Linux/macos/windows. Which is arbitrary and frustrating. I hope wasm/wasi eventually becomes the standard for libraries like this. Then the binaries/packages we distribute can work in different languages, different OSes and different architectures without needing all this drama. Wasm bundles fit perfectly in pip/npm/etc. Write them in any language you want and they run fast & run everywhere.
- epage 6y ago
  I'm torn on this, In the past, I've been broken by changes breaking me. On the other hand, you have you have an open source project that has to deal with the schedule/quality/cost trade off and people are expecting support for particular platforms without there being funding coming in to support those efforts. How much free work do they do so other people's company's continue to function?
  - johnmaguire2013 6y ago
    Yeahhh, I understand the frustration of a breaking change to the build system, but I don't understand the vitriol at the maintainers. Ultimately, projects upgrade/move. If you are dependent, that's something you need to deal with. If you're not ready to deal with it, then pin your dependencies until you are. Many of the issues in the thread aren't necessarily problems with cryptography - for example pip not being able to deliver wheels to Alpine.
- deleted 6y ago
  [deleted]
ink_13 6y ago
The authors aren't exactly cloaking themselves in glory either, to be fair.
Dansvidania 6y ago
I get that the maintainers do what they want, but following semantic versioning should prevent this kind of problems.
- epage 6y ago
  Its not clear cut what all is included with semver. Is switching from a C89 to a C99 a semver-breaking change? Is using a Python 3.1-specific function a semver-breaking change? Is fixing a bug or adding a new feature a semver breaking change [1]? There is no clear cut answer in all of these situations and applying purity tests to semver instead just push another crowd of developers to abandon semver completely, making it hard to get any information communicated from your dependencies up to you. [1] https://xkcd.com/1172/ https://xkcd.com/1172/
  - johnmaguire2013 6y ago
    Furthermore, semver states: > MAJOR version when you make incompatible API changes,[0] A build-time change isn't an API change, at least in my understanding. [0] https://semver.org/ https://semver.org/
guitarbill 6y ago
.. and to pin dependencies, or expect the occasional CI breakage. (you could argue a major version bump would've been nice instead of a minor one. but i don't even want to open that can of worms.)
- moosingin3space 6y ago
  Honestly, even with minor versions, I'd prefer to use something like dependabot, or for a bot to open a pull request bumping versions. Tons of authors mess up semver in subtle ways, it's just much easier to avoid problems if you just pin dependencies. I've started doing this with Nix for my own Rust projects, using the technique described here[1]. Planning on setting up a GitHub workflow to automatically open pull requests with bumped versions of nixpkgs/rust. [1]: https://christine.website/blog/how-i-start-nix-2020-03-08 https://christine.website/blog/how-i-start-nix-2020-03-08

deleted 6y ago

[deleted]

I bet you will be just as pissed off when others break your environment too... It's for this reason I've never liked the sprawling dependency-of-dependency mess that a lot of software projects seem to have.

josephg 6y ago
Yes; it’s particularly bad when you mix languages like this. I maintain the nodejs foundationdb libraries. Fdb doesn’t have a published wire protocol - bindings are expected to wrap a dynamically linked C library which contains the protocol implementation and net code. And that library is very “clever” - it leans heavily on codegen (via mono) and hand written asm to support a high performance actor model internally. The downstream effect is that FreeBSD support for database clients has only been added recently. There’s no native Apple M1 client support. There’s been issues with code signing in Java ... and so on. Generally you can only talk to a foundationdb server from an x86_64 client that runs Linux/macos/windows. Which is arbitrary and frustrating. I hope wasm/wasi eventually becomes the standard for libraries like this. Then the binaries/packages we distribute can work in different languages, different OSes and different architectures without needing all this drama. Wasm bundles fit perfectly in pip/npm/etc. Write them in any language you want and they run fast & run everywhere.
epage 6y ago
I'm torn on this, In the past, I've been broken by changes breaking me. On the other hand, you have you have an open source project that has to deal with the schedule/quality/cost trade off and people are expecting support for particular platforms without there being funding coming in to support those efforts. How much free work do they do so other people's company's continue to function?
- johnmaguire2013 6y ago
  Yeahhh, I understand the frustration of a breaking change to the build system, but I don't understand the vitriol at the maintainers. Ultimately, projects upgrade/move. If you are dependent, that's something you need to deal with. If you're not ready to deal with it, then pin your dependencies until you are. Many of the issues in the thread aren't necessarily problems with cryptography - for example pip not being able to deliver wheels to Alpine.
deleted 6y ago
[deleted]

ink_13 6y ago

The authors aren't exactly cloaking themselves in glory either, to be fair.

Dansvidania 6y ago

I get that the maintainers do what they want, but following semantic versioning should prevent this kind of problems.

epage 6y ago
Its not clear cut what all is included with semver. Is switching from a C89 to a C99 a semver-breaking change? Is using a Python 3.1-specific function a semver-breaking change? Is fixing a bug or adding a new feature a semver breaking change [1]? There is no clear cut answer in all of these situations and applying purity tests to semver instead just push another crowd of developers to abandon semver completely, making it hard to get any information communicated from your dependencies up to you. [1] https://xkcd.com/1172/ https://xkcd.com/1172/
- johnmaguire2013 6y ago
  Furthermore, semver states: > MAJOR version when you make incompatible API changes,[0] A build-time change isn't an API change, at least in my understanding. [0] https://semver.org/ https://semver.org/

guitarbill 6y ago

.. and to pin dependencies, or expect the occasional CI breakage. (you could argue a major version bump would've been nice instead of a minor one. but i don't even want to open that can of worms.)

moosingin3space 6y ago
Honestly, even with minor versions, I'd prefer to use something like dependabot, or for a bot to open a pull request bumping versions. Tons of authors mess up semver in subtle ways, it's just much easier to avoid problems if you just pin dependencies. I've started doing this with Nix for my own Rust projects, using the technique described here[1]. Planning on setting up a GitHub workflow to automatically open pull requests with bumped versions of nixpkgs/rust. [1]: https://christine.website/blog/how-i-start-nix-2020-03-08 https://christine.website/blog/how-i-start-nix-2020-03-08