I just created a dub package. Frankly, the whole thign is backward.

deadalnix deadalnix at gmail.com
Sat Apr 23 20:15:27 UTC 2022


So, I have this nice little project, sdc. It builds using make, 
and everything was good. People wanted it to be distributed via 
dub, so be it, let's create a dub.json file.

Ho, you wanted to distribute a package? Well, now you have a new 
build system. make was working great for you? Too bad. Can dub 
run make? It doesn't look like it but who knows. I don't.

Ok, now I have two build systems, including one I never asked for 
nor have any need for, it is now time to register the package in 
the dub registry. I need to create an account, so far so good. I 
can now register the package.

Not so quick, the registry tells me. `A "license" field in the 
package description file is missing or empty. Check your 
dub.json.`. I check the dub.json and indeed, it has no license 
field. I had a suspicion, it was created minutes ago and my 
memory is still working. I'm not sure what to put in there. Will 
dub complain if I put a license it doesn't know about? The 
project is under the MIT licence, so I decide the put the value 
at `MIT` and push the change, hoping for the best.

The registry seems happy with the license change. I still don't 
if it expected something specific or if I could have put anything 
in there, either way, it seems to be happy with MIT. On the other 
hand, on the other hand, `The repository must have at least one 
tagged version (SemVer format with a "v" prefix, e.g. "v1.0.0" or 
"v0.0.1") to be published on the registry. Please add a proper 
tag using "git tag" or equivalent means and see 
http://semver.org/ for more information.` .

This must be a new requirement that came up over the last 5 
minutes, because nothing told me about this before. I tag master 
as `v0.0.1` and push the new tag. I'm glad dub is now not only 
replacing my build system, it is also now dictating the release 
process. It turns out I have several applications in that 
repository, but thanks to dub, I don't have to ask myself the 
question of whether I want to use the same version number for all 
of them or not.

Now the package exist, and while I never asked, I also found 
myself having to commit to a new build system and a release 
strategy.

Let me blunt: this is bullshit. While I make fun of the poor UX 
and its guessing game, this ultimately is something that isn't a 
blocker. However, this whole my way or the highway attitude to 
everything is everything i don't want in a software.

I want tool to work for me, not work for the tool. I want to 
publish a package, not commit to a new build system. I never 
asked to be told how to assign version number to the different 
applications int he repo, or even whether I should put several 
application in the same repo or not. dub told me what to do to a 
degree that is almost disrespectful and is a big "fuck you" from 
the D ecosystem to anyone who want to integrate with it.

Why do we use a package manager that expect everyone to use it to 
work in a certain way? It is blatantly obvious that many 
organization out there are not going to use the exact setup dub 
expects. So what do they do if they want to adopt D? Not use dub 
at all? It's an option, but everything is distributed via dub 
nowadays in the D ecosystem. Use dub to build everything? Fork 
their own version of dub? No, the only sensible path forward for 
pretty much any organization stumbling on this bullshit is to not 
use D at all because none of the crap we put out there is going 
to play nicely with what they already have.

Anyways, enough said. I'm don't think this post is going to 
dramatically change things, but it needed to be said. The total 
disregard for users is so endemic I cannot wrap my head around 
how this has been embraced by the community.


More information about the Digitalmars-d mailing list