On Tuesday, 13 June 2023 at 15:34:28 UTC, Martyn wrote:
> Ok, now I need to use some libraries. DUB is great for this! However, when I search for packages, how do I know which version they support?
Actually, dub already allows specifying toolchain requirments. https://dub.pm/package-format-json.html#toolchain-requirements . But it hardly helps with solving the issue of breakage, as some packages may require different versions of frontend and there is no way to solve it. Actually, someimtes, even dub packages themself can break because they depend on different versions of the same package, but at least 3rd party is usually strong enough in guaranteeing compatibility within certain major version.
> Are we expecting maintainers of these libraries to keep them up to date monthly? Lets be honest.. if I need to include 3 DUB projects into my application then what are the chances they have been tested on 2.104.0? It is highly unlikely. The next question is - what version should I be using? Atleast 4 versions old?
I don't know what the "expectancy" is, but talking with a lot of D developers led me to one conclusion: everyone expects you to have your own standard library. And then everyone expects you to use as little of the language as possible. And then everyone expects you to write your own code anyway, because there's an informal agreement that "dependencies bad".
This is a chicken and egg problem, really. Is there no packages because nobody writes them because "dependencies bad", or are "dependencies bad" because every existing one just breaks?
> Now, imagine the difficulties of an application with 3 or 4 DUB packages. Each library being released/updated at different times and lord knows what version they were last tested on. Will they all work with 2.104.0?
I don't have to imagine this -- dlangui has 9 dependencies. I went through great lengths to extract them from dlangui project itself (they were initially copy-pasted into a 3rdparty folder), and I'm beginning to regret this. If any of the dependencies break, or stop updating, I'm stuck with an old compiler version essentially. And it's not like replacing dependencies is easy when they are so scarce.
> Because of potential breaking changes for each new release... could I end up with ProjectA being OK but not another, while experimenting with different dmd versions?
icontheme
dependency of dlangui is exactly what you describe. The maintainer refused to adapt to changed alias this
rules, and I will have to figure something out eventually. Possibly, it's another project that I will have to maintain by myself because of silly breakage.
> There is a reason why LTS releases exist. Look at other languages. Java, .NET, C++. Look at other projects like Linux or Blender. Could you imagine Blender users going by monthly builds only. Blender would fall apart and fast!
I agree that some form of LTS is needed, but I don't think it's going to happen with D. After all, it's not that the lack of LTS is causing issues. We could be upgrading compilers monthly without issue if those releases provided some strong guarantee of at least not changing something that results in API changes. After all, changing, eg, std.xml
to undead.xml
isn't that devastating, and doesn't affect third-party that much. I even stressed that D has become unbearable, as in it didn't introduce much breakage a few years back. Though, a stable release would still be greatly appreciated.
> Again, if we had LTS builds, our libraries can target those specifically. It also makes it easier to maintainers to plan ahead for the next LTS. As my previous post suggested, the version of the libraries can start with the LTS version. It makes it so easy to know if your version is supported, etc.
Yes, that is the whole point of this thread. To ask for some sort of stability in the D ecosystem. Because, practically, there isn't just "the latest version", there are 10 to 20 versions of D in the wild at the same time, and it's impossible to deal with.