Permalink
Reply
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.
