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