What do we do with existing dub packages?

[quickfur]

What's our policy wrt code.dlang.org packages? Obviously outright breaking them isn't an option, we need all the help we can get to have existing people move over here, which means we can't just totally break all their existing dub projects. But as this fork diverges from upstream, there's bound to be incompatibilities with upstream dub packages. What should be the solution here?

One idea is to use a selective forwarder for opend's equivalent of dub: it would redirect requests to upstream dub for most cases, but maintain a blacklist of packages that are no longer compatible, for which it would redirect to an alternative opend-specific substitute, or return an error if no substitute is available. (Kinda similar to what Devuan, a Debian fork, is doing for their package repo.)

[adamdruppe]

What I want to do for libraries is make it more of a centrally managed thing. It doesn't scale infinitely but it is much easier to use and we have the option of doing updates ourselves in here.

My dislike of dub is no secret anyway, so some kind of full replacement is in order. Most the code there will probably not break for a while anyway; I'm kinda conservative when it comes to language breakage.... but I'm not necessarily the dictator so we'll see what happens. Still there's so much other work to do i don't see us breaking that much for a while.

[quickfur]

The problem with things like xmake is that everyone has their favorite make replacement, but nobody can agree on which one is the best.

[adamdruppe]

we could choose for them and bundle something with the distribution. (assuming i ever figure out how to make a distribution)

[kassane]

And how much reggae will be completely discarded by openD?

I just read Adam's note and it seems disappointing.
http://dpldocs.info/this-week-in-d/Blog.Posted_2023_09_11.html#reggae-editorial

I've never tried D1, but I've seen build.d in some old projects. Would it be interesting to resurrect and improve this feature?

[adamdruppe]

Reggae can, in theory, work with all kinds of build systems, but yeah, I've never found it to be of significant value.

My preference is to use dmd -i which automatically finds needed library files and builds them all in one go, assuming it can find them. I wanna make the opend driver use that as the base rather than dub. In some cases it won't work, and then maybe something like reggae will work, but I'd rather avoid the use when we can.

[quickfur]

In cases like this where the default thing doesn't do everything for everyone, my personal approach is to let the default thing do its job, but provide an easy way for the user to customize it. In this case, we could have the default build thing take a special command that spits out a makefile or csv of dependencies or whatever, that the user can then import into their favorite build tool.

Basically the idea is, empower the user. The default way is the convenience thing we offer you, if you don't like it, here's how to get the necessary info to roll your own. Don't go the way of dub's philosophy where you either fit in or you're left out in the cold.

[quickfur]

In an ideal world I prefer package management to be separate from building. This can make it more inconvenient for the end user, but would solve a lot of the limitations built into dub right now.

One approach is to bundle it by default so that the easy use cases are still as easy as before, but internally design it separately so that for unusual use cases it's still possible to make it do the right thing, without having to throw out the baby with the bathwater like you have to with dub when you need to go beyond what it was designed to do.

[jmh530]

You bring up dub packages, but the issue extends to existing D libraries more generally. If existing D code cannot be compiled with openD or otherwise existing D libraries cannot be used with it, then it places a burden on existing D users to transition to openD.

[IgorDeepakM]

It's not an if, the departure from old D code happened almost at day one with DIP1036 and it looks like the old D project is going another direction. As soon a library uses interpolated string, there is a comparability issue. Now libraries today are likely not to use interpolated strings but I expect that in time D and openD will diverge more and more (which I hope). The goal with openD was to continue to evolve D and make it better. However, we should consider ways to overlap functionality in order to make porting easier. For example keep version identifier at the same time allowing the new compile time defines.

This in practice means that openD needs an own package management system and existing D libraries might need to be ported. If openD becomes successful, library owners will likely port the library themselves.

[jmh530]

Even if I were enthusiastic about openD's direction (some ideas are good, but there's enough I'm not on board with that it's not really for me), there is absolutely zero chance I am going to invest manual effort to port D code to openD. If you want openD to be a D successor language. You'll have better chance of this fork being successful (even if the fork isn't for me) if you have the ability to make a smooth transition (whether that is some kind of automatic translation or the equivalent of importD, I don't can't say).

[adamdruppe]

What is it you're not onboard with? Very little is set in stone here.

[jmh530]

My focus with programming is related to statistics, linear algebra, and optimization. So @nogc/betterC/importC are all stuff that (to me) makes the D language more attractive, rather than less (though I am still annoyed about importC and h files). I am unenthusiastic about things like @safe by default. I think your string interpolation stuff is better than Walter's and a few other things look interesting, but it's not exciting enough for me to exert effort.

That being said, I am still working on mir-stat and hope to get it into a position that I am happy with, but with Ilya no longer contributing much to the other mir projects my motivation for D has been waning a bit [1]. I don't think this fork will change that (so feel free to ignore me), but it would be nice if the code I write in D can be used by people using this fork without much trouble. I probably would have been better off putting my efforts into C++, but D is just so much nicer. I certainly have learned a lot about programming by writing D code.

[1] There's this big thread on Hacker News today about Polars and I'm still kind of annoyed that D is so far behind on data frames. But I'd rather write C++ than Rust.

[adamdruppe]

OK yeah, I'm actually not sure if safe by default is going to work irl yet either, I wanna try it on some real code (remember, my ARSD libraries are a quarter million lines of code by themselves, and now with this fork, I have about another 3/4 of a million adopted, so there's a lot of inertia on my end; if any change ends up too much work for me i'll probably revert it lol) and see what happens. My gut feeling is actually that safe by default won't be a huge burden since I expect most functions will be ok on it and some trusted here and there can paper over it... but only way to know for sure is to try it.

Of course, nogc etc, I wrote a little more about this in my blog last night: http://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.html#gc my philosophy is more about shifting priorities than outright breakage because it is useful somewhere... but I also suspect for much of that much of mir, for example, would continue to work just as well if nogc were to be ignored. Again though, the final decision is always gonna be made after experimenting with it a bit since it is always possible I'm just plain wrong about my guesses.

[quickfur]

It's not an if, the departure from old D code happened almost at day one with DIP1036 and it looks like the old D project is going another direction. As soon a library uses interpolated string, there is a comparability issue. Now libraries today are likely not to use interpolated strings but I expect that in time D and openD will diverge more and more (which I hope). The goal with openD was to continue to evolve D and make it better. However, we should consider ways to overlap functionality in order to make porting easier. For example keep version identifier at the same time allowing the new compile time defines.

Currently, upstream has not merged any string interpolation implementation yet, and who knows how long it will be before they come to any agreement on it. So in the meantime, there will be no interpolated strings in upstream code, which means they will be compatible with openD, at least the current state ot it. The transition is unfortunately only one-way: DIP1036e interpolation string syntax does not parse with upstream D, so even a version block would not help with compatibility here (I tried). Ironically, once i"..." syntax is merged upstream you'll be able to version code to be compatible each way. Though it becomes a bit tricky as i"..." meant for one fork compiled with the other may produce subtle runtime flaws.

One thought is to implement some way of maintaining backward compatibility, such that upstream code, at least existing upstream code sans new divergent features, will always be compilable with openD, it just won't take advantage of new changes. Maybe a compatibility mode in the compiler or something that retains the old semantics, turned off by default.

This in practice means that openD needs an own package management system and existing D libraries might need to be ported. If openD becomes successful, library owners will likely port the library themselves.

Yeah we're gonna hafta recreate all of this infrastructure. It isn't going to be easy. To mitigate the difficulty we probably should have some bridging mechanism for importing existing dub libraries without additional effort. Any hindrance in this area means less adoption of openD. Maybe something like what Devuan does with Debian repos: they don't clone the entire Debian repo as that's too onerous, instead, they have a redirector that redirects most requests to the Debian repos except for a few hand-crafted exceptions that are replaced with Devuan-specific packages, and a blacklist of a small number of incompatible packages. Essentially a "diff" against Debian, if you will. So basically what we need is a "diff" against code.dlang.org, with a replacement list and a blacklist.

[adamdruppe]

It is easy to write libraries that are compatible with OpenD interpolation and with upstream D because OpenD interpolation puts a concrete type you can overload on. If that type doesn't exist, you can polyfill it with static if(!__traits(hasMember, core.attribute, "...")) in such a way that the library can support it if is there and still compile (just without the benefit of the new feature) if it isn't.

[quickfur]

The breaker is that once you use interpolated strings, your code won't parse anymore in upstream D, even if you try to version it out or use a static if. This is because i"..." is not valid syntax in upstream D. This problem will only go away once upstream merges whatever version of string interpolation they choose to make i"..." syntactically-acceptable.

The only workaround I can think of is to wrap interpolated strings inside a mixin, but I'm sure you can see the disadvantages of doing that.

[adamdruppe]

Yeah, but that's user code which I'm less concerned with than library code. Library code can accept an interpolated string without using it, and user code is generally allowed to have stricter requirements than library code.

[bachmeil]

That being said, I am still working on mir-stat and hope to get it into a position that I am happy with, but with Ilya no longer contributing much to the other mir projects my motivation for D has been waning a bit [1]. I don't think this fork will change that (so feel free to ignore me), but it would be nice if the code I write in D can be used by people using this fork without much trouble. I probably would have been better off putting my efforts into C++, but D is just so much nicer. I certainly have learned a lot about programming by writing D code.

Related to this point, there are relatively simple changes D could make that would improve the experience for this type of work:

• Add additional operator overloading. The current available operators are too limited (for instance, you can't have both matrix multiplication and element-by-element multiplication, there's no convenient way to write a sequence in general, and there's no way to indicate all rows or columns when slicing a matrix).
• Kill dub.json. It's horrible to require a configuration file when in other languages you just use an import statement in your code. It's also unncecessary.
• Add other extern declarations like extern(R) and extern(Matlab). After compiling to a shared library, you could load in R, Matlab, or whatever. I know this is easy to do, because I've already done it for R.

I had an unfinished blog post sitting around for months because I knew this would never go anywhere with upstream D. I thought about ways to do it myself but never had the time. If OpenD were to implement them, it would be a genuine improvement over upstream for this type of work. https://bachmeil.github.io/the-blog/2024/01/09/numerical-limitations.html

[adamdruppe]

Kill dub.json. It's horrible to require a configuration file when in other languages you just use an import statement in your code. It's also unncecessary.

I've been saying this for years! I personally don't even use dub, it is pointless. I have ideas for migrations though just gotta find the time to do it. Never bothered before tho cuz it doesn't benefit me (my libs already work for me) but can do it here for the opend community when i get around to it.

The other stuff there sounds cool too, we can work it out.

[adamdruppe]

On the topic of operator overload, the tokens there look unambiguous. So the compiler could define precedence for them hardcoded but do nothing behavior wise except forward it to the overload. It does this for multi-dimensional arrays (which need a standard implementation! maybe we'll just borrow mir's)

[jmh530]

Add additional operator overloading. The current available operators are too limited (for instance, you can't have both matrix multiplication and element-by-element multiplication, there's no convenient way to write a sequence in general, and there's no way to indicate all rows or columns when slicing a matrix).

I think I raised these several years ago to Walter when I first started reading about D. Python added the @ operator for matrix multiplication probably around that time. I think I like R's %*% more (since you can use that a bit more flexibly and it's a bit like "here be dragons" which might have made Walter a little more enthusiastic).

Add other extern declarations like extern(R) and extern(Matlab). After compiling to a shared library, you could load in R, Matlab, or whatever. I know this is easy to do, because I've already done it for R.

Yeah, that's a great idea, particularly if you add extern(python) to that list. You've been 100% right about the importance of interacting with these other languages. (Admittedly importC is also about using libraries from other languages).

To your comments, I would add some kind of fix for issue 1807, whether that be a direct fix or indirectly with some kind of concepts approach like C++. I've been writing a function to return squared Mahalanobis distance and it just gets really complicated when you're potentially handling the case of whether your data is a positive definite matrix or a Cholesky matrix and whether you're using packed storage or not or the precision matrix instead of the covariance matrix (or inverse Cholesky). There are significant performance improvements if you know what data you are dealing with. I ended up taking the approach of just naming them separate functions and the user can decide what they want to use, but the API could be much simpler if there were a solution for that.

[jmh530]

It does this for multi-dimensional arrays (which need a standard implementation! maybe we'll just borrow mir's)

Ilya had made an offer over the summer to move parts of mir into druntime: https://forum.dlang.org/post/szljgyqtwfangdygcifs@forum.dlang.org
But his conditions were considered too restrictive and there were licensing issues.

C++'s mdspan (for C++ 23) might be another source of inspiration.

[quickfur]

[...]

Related to this point, there are relatively simple changes D could make that would improve the experience for this type of work:

* Add additional operator overloading. The current available operators are too limited (for instance, you can't have both matrix multiplication and element-by-element multiplication, there's no convenient way to write a sequence in general, and there's no way to indicate all rows or columns when slicing a matrix).

What operators would be needed?

* Kill dub.json. It's horrible to require a configuration file when in other languages you just use an import statement in your code. It's also unncecessary.

I'm no fan of dub either. It's just too restricted and refuses to understand that there exists a world outside of its own. And it does a whole bunch of unnecessary stuff that I don't need, yet it makes me pay for it. We need a better model.

Auto-scanning imports sounds like an awesome way of doing this. Maybe a compiler-based tool that downloads dependencies based on the imports parsed by the compiler would be the ticket. There are technical issues to be resolved on this front, though. Like allowing the user to override cache settings, use a local package repository, etc.. But no insurmountable challenges that I can think of, as long as we're willing to put in the work to implement it.

* Add other extern declarations like extern(R) and extern(Matlab). After compiling to a shared library, you could load in R, Matlab, or whatever. I know this is easy to do, because I've already done it for R.

What kind of compiler support would be needed for these new extern types? If this requires a lot of compiler changes I'm not sure if it will fly.

OTOH, if the compiler can expose some kind of generic internal API for adding foreign language support, then this could potentially become a killer feature. For example, if we didn't have to change the compiler in order to have extern(java) pull in arsd.jni along with all the hooks and glue code for making Java interop work. Perhaps some kind of external compiler plugin that you could optionally install to get interop with specific foreign languages.

I had an unfinished blog post sitting around for months because I knew this would never go anywhere with upstream D. I thought about ways to do it myself but never had the time. If OpenD were to implement them, it would be a genuine improvement over upstream for this type of work. https://bachmeil.github.io/the-blog/2024/01/09/numerical-limitations.html

I'm not so sure about adding additional operators to the language that doesn't do anything by default. I sympathize with the need for custom operators, but I'm just not sure how to do it in a way that doesn't end up being a mess. If we add a '**' operator, for example, that could break subtle lexing cases like multiplying numbers dereferenced from pointers. But assuming we choose a syntax that doesn't have such problems. Then there's the question of what the operator should mean in the default language outside of overloads. What precedence should it have? What should it do by default, since there's no basic operation it could correspond to with basic types? And how many of these custom operators do we need, how should they be named, what precedence/associativity should they have, and when do we stop?

One solution I can think of is to use Unicode math operators that already have a clear meaning in math. But that brings up the issue of how to easily type Unicode operators in your code -- if the user has to open up a Unicode character map to select the operator every time it's needed, it's going to be a no-go because of its impracticality.

Either way, the question of precedence and associativity still stands. You still have to assign a precedence and associativity to every custom operator, and do it in such a way that an expression involving a mix of these operators with the current ones is still readable and easily understood. Having user code define precedence/associativity is a no-go, because it means the compiler has to parse such definitions before it can lex expressions that use these operators -- this immediately brings us into the C++ realm of complexity (and unmaintainability -- OpenD code would become unreadable if operator precedence depends on what you import -- even C++ isn't bold enough to do this).

[bachmeil]

I don't object to this, but I'd hope we could still add non-unicode alternative versions of * and /. A user of the other languages wouldn't find unicode symbols to be all that helpful. They'd certainly find it odd to have to insert symbols not on their keyboard instead of typing %*% or .*. It would also be undesirable to add a dependency on VS Code and a plugin - I don't use VS Code.

[adamdruppe]

could always treat the trigraph as equivalent to other thing. tho tbh that's prolly a decent complication so .... better to pick one or the other i suspect.

worth noting many editors do support macros like that. so vim lets you set "abbreviations" so you type one sequence and it turns into something else. but like don't put too much weight on anything i say here; this isn't my domain so i'd defer to those of you who do

tbh i suspect my preference is to have a named method anyway, and the operator overload then just forwards to that. so like

Vector crossProduct(Vector rhs) { }

alias opBinary(string op : "X") = crossProduct;

that kind of thing so if you dont' wanna type out the special X you can still do .crossProduct()

[jmh530]

Julia allows the use of unicode symbols for function names. I was never that enthusiastic about the idea, mainly for the same reason @bachmeil brought up. You either need an IDE or customize your text editor (in a way that isn't entirely obvious to new users to your language).

I think only a little more flexibility on operator overloading is needed from a linear algebra perspective. R, Matlab and Python have separate ways to handle element-by-element matrix multiplication and normal matrix multiplication. But it's not like they have a plethora of new symbols. There are a few different ones that make the users life a little easier for a particular use case. The open question would be whether you want to be just a little more flexible than D or allow greater customization.

Matlab and Python are a bit more locked down with respect to operator overloading, while R allows more customization. R allows a %op% b where op is pretty flexible. For matrix multiplication, you would use a %*% b and there are a few other standards, but if you see one you don't recognize you immediately know it's some kind of operator overloading that is not standard. If you allow op to be unicode, then you can do unicode operators that way.

I think the column access thing is more of a no-brainer. Allow a lowering of X[, 1] or X[..,1] to X[0..$, 1].

[quickfur]

I think the column access thing is more of a no-brainer. Allow a lowering of X[, 1] or X[..,1] to X[0..$, 1].

+1, this is totally the easiest way to solve this issue. I'd go with .., because allowing the empty sequence to stand for something is likely to run into parser/lexer ambiguity issues.

As for %op%, I was thinking if op can be an identifier that would allow custom operators for free. But then I realized that it would lead to parser problems because it could be parsed as two modulo operators with an identifier operand. But if there was a way to make it unambiguous it would work, and would be self-documenting, e.g. A %dotProduct% B or A %dot% B is immediately clear what it does, had it not been for the ambiguity with binary %. I can't think of any way of making it unambiguous, though, since pretty much all ASCII symbols have been assigned a preexisting meaning.

[jmh530]

But then I realized that it would lead to parser problems because it could be parsed as two modulo operators with an identifier operand.

Maybe that's why R uses %% as the mod operator instead of %.

But if there was a way to make it unambiguous it would work, and would be self-documenting, e.g. A %dotProduct% B or A %dot% B is immediately clear what it does, had it not been for the ambiguity with binary %.

Is my understanding correct that the ambiguity would manifest if you have a variable named dot?

In R, you don't get these for free with every function that has two inputs, you have to define them as functions. Putting it in D terms (and cribbing Adam's example above), it might be something like

double dot(double[] a, double[] b) { //impl;}
alias opBinary(string op = "%dot%") = dot;

I would think the parser could see the %, then look ahead. If it is one of the limited set of overloaded %op% functions, then it would use that. Otherwise, it would treat it like normal.

[bachmeil]

Kill dub.json. It's horrible to require a configuration file when in other languages you just use an import statement in your code. It's also unncecessary.

I've been saying this for years! I personally don't even use dub, it is pointless. I have ideas for migrations though just gotta find the time to do it. Never bothered before tho cuz it doesn't benefit me (my libs already work for me) but can do it here for the opend community when i get around to it.

I don't actually mind Dub as a way to install packages. I can use dub add-local on a repo I've cloned and it will know how to handle C library dependencies or any other dependencies. I just don't understand why I have to create a configuration file to use the dependency. If I'm importing foo.bar and I haven't specified anything in my compilation command about where to find foo.bar, it should look in the package installation directory. I don't need a configuration file to tell it where to find std imports.

So the compiler could define precedence for them hardcoded but do nothing behavior wise except forward it to the overload.

There wouldn't be a ton of new operators needed for operator overloading (additional versions of * and / would be the primary cases I think). I'd expect them to have the same precedence as the current * and /.

Yeah, that's a great idea, particularly if you add extern(python) to that list.

Yes. And now that I think about it, one of the Octave developers was posting on the mailing list about using D as an extension language for Octave, so extern(Octave). Maybe even extern(Fortran) since that's severely limited outside of numerical functionality. It already has C interoperability built in.

[jmh530]

Wouldn't extern(Octave) be the same as extern(Matlab)?

[bachmeil]

I'm not sure. I know you can use Mex files from Octave, but they recommend Oct files for performance reasons. My initial thought (without having ever done much with either Octave or Matlab) is that we'd be doing something like this: https://docs.octave.org/latest/Calling-External-Code-from-Oct_002dFiles.html According to this page: https://docs.octave.org/latest/Getting-Started-with-Oct_002dFiles.html you can pass .o files to mkoctfile.

[bachmeil]

What operators would be needed?

At this point, not many: alternative versions of * and /, something that lets you define a sequence of the form 2..8, and something that allows you to specify all rows or columns of a matrix, like x[,4] or x[:,4]. Maybe there are others I'm missing, but these would be a major improvement.

What kind of compiler support would be needed for these new extern types? If this requires a lot of compiler changes I'm not sure if it will fly.

In the case of R, nothing beyond recognizing extern(R). I know because I've done it: https://github.com/bachmeil/embedrv2

From the example on that page:

@extern_R ar1irf(double alpha, double shock, int h) {
	double[] result;
	result ~= shock;
	foreach(ii; 1..h) {
		result ~= alpha * result.last;
	}
	return result;
}
mixin(exportRFunctions);

double last(double[] v) {
	if (v.length > 0) {
		return v[$-1];
	} else {
		return 0.0;
	}
}

That converts ar1irf to something that can be called from R. All the compiler needs to do is add an import to a file and a mixin.

I sympathize with the need for custom operators, but I'm just not sure how to do it in a way that doesn't end up being a mess.

I'm not proposing custom operators. If we go that route, however, we definitely wouldn't want custom precedence. R has custom operators and they all get the same precedence. Actually, custom precedence is already supported by D, in the form of appropriately placed parenthesis.

I want to emphasize the importance of having an adequate set of operators for this kind of work. Lisp has always suffered from writing things in the form (+ 4.6 1.2). D supports 4.6 + 1.2 because add(4.6, 1.2) doesn't feel natural, but it's not that different to tell someone to use elmul(x, y) for element-by-element multiplication.

[quickfur]

Hmm cool, so all it takes is (1) a way to introspect marked functions by iterating over declarations, and (2) inject some code to generate the glue between them. I can see how this could be a general mechanism:

1. Add __traits(externFunctions, lang) or something like that to get a compile-time list of functions declared as extern for foreign language `lang;
2. When the compiler sees extern(abc) where abc is unknown to the compiler, pass the declaration to some standard extern-handling hook function, maybe say a template generateExternBinding(string lang, alias decl) that will do whatever it takes to make the binding work.

This would work for most bindings where all we need is some kind of wrapper to forward the call. For the cases where something more involved is required, such as different mangling, calling convention and other ABI differences, we just implement it in the compiler. There shouldn't be very much in the latter category anyway since we already have extern(C) and extern(C++).

As for operators:

I've written my own linear algebra modules before, and what I ended up doing is to take advantage of UFCS: matrixMul(x, y) becomes x.mul(y). The parentheses unfortunately can't be omitted, but it already reads a lot better than mul(x,y) especially when x and y may be nested with other operators. Not ideal, certainly, but at least gets you partway there.

As far as custom operators are concerned, I guess we could come up with a short list of such, with clearly defined precedence and associativity, and just add them as long as they won't cause any lexing/parsing issues. I'd want to err on the side of fewer rather than more custom operators, though, just to be a bit more conservative in terms of language changes.

[bachmeil]

As for %op%, I was thinking if op can be an identifier that would allow custom operators for free. But then I realized that it would lead to parser problems because it could be parsed as two modulo operators with an identifier operand. But if there was a way to make it unambiguous it would work, and would be self-documenting, e.g. A %dotProduct% B or A %dot% B is immediately clear what it does, had it not been for the ambiguity with binary %. I can't think of any way of making it unambiguous, though, since pretty much all ASCII symbols have been assigned a preexisting meaning.

It wouldn't work in the general case, but it should for overloading any existing unary or binary operator, or any identifier that starts with one of those operators or a .. I also think @dotProduct@ would work. I don't know of valid syntax that would be an identifier followed by @ with no space in between.

[GrimMaple]

Sine I've already started the opend thing, I'll share my thoughts on this as well.
First of all, there aren't many dub packages worth supporting in the first place. Just a few of them, which can be maintained manually if needed.
Second, in my ideal world saying opend should Just Work, and you wouldn't even need any configuration at all. Realistically, many of the dub packages can be built by just compiling all .d files from src folder, which is what opend does right now. I'm gonna add a temporary -i argument that would look for library code in a specified path. Then we'll see how far that goes and I'll adjust accordingly.
P.S. I do plan on creating a better package repository as a result.

[andrey-zherikov]

My main complain about packages in code.dlang.org repo is that there are a lot of useless junk like "my test program". I'd like to see some moderation there including removing unsupported packages.

[denizzzka]

There aren't so many packages. Therefore, even when I have to choose from several, it’s not difficult to look through them all with my own eyes.

At other hand, delegating part of work to the some "moderator" is a bad idea from many points of view.

[adamdruppe]

My power is still out so no access to my main computer to double check, but I did a test ... i think last year and found that the top 50 packages accounted for like 98% of the code and downloads. Indeed, the top 10 alone were like 50% of it or something like that. There's a lot in a little then a little in a lot.

It should be perfectly reasonable to focus efforts on the top ones, including just fixing them all to account for certain changes.

[quickfur]

CI is supposed to help with that. Fork the top dub repositories and put them in CI, whenever it breaks from a languagechange update them

[GrimMaple]

I do have a plan on how we could organize the dependency repository (at least temporarily), but that will happen later on. Worst-case scenatio, again, we can just maintain those 10 packages manually.